cast(extract(epoch from current_timestamp) as integer) , это единственный способ конвертить timestamp в integer ?

cast(extract(epoch from current_timestamp) as integer) , это единственный способ конвертить timestamp в integer ?

Другое мне не известно

День добрый. Вопрос для успокоения собственной совести ? Имеем таблицу созданную как CREATE UNLOGGED ... в которую пишет множество процессов и в ней очень много INSERT\UPDATE. С небольшой периодичностью таблице делается TRUNCATE TABLE. Для таблицы хочется отключить autovacuum и autoanalyze, т.к. колчичество изменяемых строк огромно, и соответственно тригерится ANALYZE\VACUUM Насколько я понимаю, мы безопасно можем создать её с WITH ( autovacuum_enabled = false, toast.autovacuum_enabled = false ) и не беспокоиться о dead tuples т.к. TRUNCATE эффективно освобождает дисковое пространство, не требуя VACUUM. Так ли это?

если бы вы не делали update, то автовакуум бы туда и сам не пришёл никогда

cast(extract(epoch from current_timestamp) as integer) , это единственный способ конвертить timestamp в integer ?

psql -h 192.168.247.129 -p 5432 -d dd -Atc 'select current_timestamp::abstime::integer' && date +%s 1519040896 1519040896

Увы, туда аггрегируются данные, делается т.н. UPSERT

psql -h 192.168.247.129 -p 5432 -d dd -Atc 'select current_timestamp::abstime::integer' && date +%s 1519040896 1519040896

Спасибо

Коллеги, может еще у кого появятся мысли по моему вопросу?

Ребяты, привет. Отвлеку немнгго. Есть задача, никак нетмогу к ней решение красивое придумать. Есть деталь, она лежит на складе. Складов много, у каждого есть один или несколько префиксов - русская буква или несколько букв. У каждой детали должен быть номер детальки из префикса и номера детали на этом складе, относительно префикса. Как такую штукенцию сделать?

Номера последовательные

Пример: М-132, К-30

Как это все генерить и хранить?

Я пока вот склоняюсь к одной таблицы, у каждой детальки будет свой id, и при добавлении генерить ей порядковый номерок относительно префикса бквенного

Вот как генерить нетмогу понять. Может сиквенс отдельный

И как хранить такую конструкцию, чтобы индексировать ее номально: префикс и номер в отдельных полях или можно в одном хранить строчном?

Вопрос при /usr/pgsql-10/bin/postgresql-10-setup initdb -D /usr/pgsql-10/data/ пишет что ключа -D нет. в доках пусто, ос Centos 7

Вопрос при /usr/pgsql-10/bin/postgresql-10-setup initdb -D /usr/pgsql-10/data/ пишет что ключа -D нет. в доках пусто, ос Centos 7

Это шеллскрипт. Посмотри в его нутрь, например.

уже весь его просмотрел нет там такого ключа дейстивтельно. но вот вопрос в доках есть и тогда как инициальзировать бд в другую папку относительно default настроек

ребята, как в SELECT для условия WHERE указать несколько значений?

OR?

SELECT * from table_name WHERE age IN (10,11,17,18);

select * from table_name where age > 21 OR city = 'Tallinn';

спасибо

День добрый. Вопрос для успокоения собственной совести ? Имеем таблицу созданную как CREATE UNLOGGED ... в которую пишет множество процессов и в ней очень много INSERT\UPDATE. С небольшой периодичностью таблице делается TRUNCATE TABLE. Для таблицы хочется отключить autovacuum и autoanalyze, т.к. колчичество изменяемых строк огромно, и соответственно тригерится ANALYZE\VACUUM Насколько я понимаю, мы безопасно можем создать её с WITH ( autovacuum_enabled = false, toast.autovacuum_enabled = false ) и не беспокоиться о dead tuples т.к. TRUNCATE эффективно освобождает дисковое пространство, не требуя VACUUM. Так ли это?

В один прекрасный момент счетчик транзакций перевалит у вас за 4млрд, и тогда все станет печально. То есть считаю что автовакуум отключать это зло.

В один прекрасный момент счетчик транзакций перевалит у вас за 4млрд, и тогда все станет печально. То есть считаю что автовакуум отключать это зло.

Не перевалит же. TRUNCATE делается на таблице у которой в storage parameters отключен автовакуум

Ну это только гадать можно. Сами же говорите что много апдейтов идет в таблицу.

Почему вакуум отключить хотите?

он там бесполезен

но из-за сотен тысяч INSERT\UPDATE срабатывает при любых настройках

TRUNCATE минимум раз в час

тогда ок

в таблице делается предаггрегация данных которые потом переезжают в другие таблицы/БД

Вопрос при /usr/pgsql-10/bin/postgresql-10-setup initdb -D /usr/pgsql-10/data/ пишет что ключа -D нет. в доках пусто, ос Centos 7

используй просто initdb без всяких сетапов

Если меня не устраивает куда инит мне бд ставит?

Если меня не устраивает куда инит мне бд ставит?

/usr/pgsql-10/bin/postgresql-10-setup эт дистрибутиво-зависимая хрень. Советуют использовать просто initdb - такая же команда как psql / pg_ctl

Или pg_dump (например)

Искать там же где и прочие бинарники Postgresql. Минус в том что придйтся самостоятельно настраиваить startup сервера при загрузке системы

Спс

Спс

А я копировал сервис и там прописывал куда база ляжет. Если интересно могу подробности глянуть. Цент+пг9.6

С 9.6 все ок. С 10 по другому((

Хотя по докам так же

С центом - по-другому) Тоже помню мучался что D не срабатывало

Но я не настоящий сварщик. Мог не туда свернуть

Вопрос при /usr/pgsql-10/bin/postgresql-10-setup initdb -D /usr/pgsql-10/data/ пишет что ключа -D нет. в доках пусто, ос Centos 7

А определить PGDATA в нужный каталог не помогает?

этот самый сетап с ключиком --help запустить - ничего не скажет по поводу переменных окружения? Помню, есть такое...

там проигнорили, сюда написал, так как вычитал что такое может слать бд в логи клиента да и людей во много раз больше, вдруг кто сталкивался, мне тут уже посоветовали с дебагом разобраться, завтра буду пробовать.

Дебаг в zabbix_server.conf уменьши

Дебаг в zabbix_server.conf уменьши

дело было не в дебаге заббикса, а в дебаге постгреса , тем не менее спасибо.

Постгрес писал дебаг Сообщения в лог заббикса оО

Постгрес писал дебаг Сообщения в лог заббикса оО

Он может писать в логи клиентского приложения в конфиге постгреса строка client_min_messages

Здравствуйте ребята и девчата! ? Подскажите мне пожалуйста, как заставить psql откатывать транзакцию если встретил ошибку, например неизвестная команда (допустим: \wrong), или же \i missingfile. Получается так, что выполнение скрипта прекращается, а транзакция коммитится даже с флагом --single-transaction (-1). Может это баг? Версия psql 10.2, PostgreSQL 10.1.

Здравствуйте ребята и девчата! ? Подскажите мне пожалуйста, как заставить psql откатывать транзакцию если встретил ошибку, например неизвестная команда (допустим: \wrong), или же \i missingfile. Получается так, что выполнение скрипта прекращается, а транзакция коммитится даже с флагом --single-transaction (-1). Может это баг? Версия psql 10.2, PostgreSQL 10.1.

Да, с —single-transaction должен откатывать... Вы уверены, что всё правильно делаете?

Да, с —single-transaction должен откатывать... Вы уверены, что всё правильно делаете?

Да, сейчас попробую написать тест-кейс

Здравствуйте ребята и девчата! ? Подскажите мне пожалуйста, как заставить psql откатывать транзакцию если встретил ошибку, например неизвестная команда (допустим: \wrong), или же \i missingfile. Получается так, что выполнение скрипта прекращается, а транзакция коммитится даже с флагом --single-transaction (-1). Может это баг? Версия psql 10.2, PostgreSQL 10.1.

Roll back?

# psql -1f test.sql CREATE TABLE psql:test.sql:4: invalid command \wrong # psql -1f test.sql psql:test.sql:2: ERROR: relation "test001" already exists psql:test.sql:4: invalid command \wrong

Получается так, что таблица все-таки создается, несмотря на то, что скрипт вызвал неверную команду и должен по-идее произойти rollback

думаю нужен BEGIN в начале скрипта (UPD: не поможет)

Получается так, что таблица все-таки создается, несмотря на то, что скрипт вызвал неверную команду и должен по-идее произойти rollback

Да, несколько неожиданно. ;) Логи при этом такие: statement: BEGIN statement: CREATE TABLE test001 (id serial); statement: COMMIT Т.е. как и документировано, psql просто делает так: It causes psql to issue a BEGIN command before the first such option and a COMMIT command after the last one, thereby wrapping all the commands into a single transaction. Из чего следует, что чисто "клиентские" ошибки ничего не прервут. Т.е. "не bug", а "читайте документацию внимательнее". ;)

В любом случае, это больше относится к psql нежели к самому серверу. Мне кажется что в версии до 9.6 было именно такое поведение, но я не уверен, нужно проверить.

Получается так, что таблица все-таки создается, несмотря на то, что скрипт вызвал неверную команду и должен по-идее произойти rollback

psql —set ON_ERROR_STOP=on -1f test.sql работает, если скрипт обернуть в BEGIN/COMMIT

Оборачивать в begin/commit нет смысла т.к. это делает команда -1

ON_ERROR_STOP=on тоже не помогает

ON_ERROR_STOP=on тоже не помогает

ну вот если добавить флаг -1, тогда создает таблицу даже если в файле есть BEGIN/COMMIT, и комитит транзакцию несмотря на ошибку

забыл добавить, версия psql 9.5.11. Может что-то сломали/исправили в свежих

Приветствую) Подскажите, пожалуйста, как написать условие что бы выбрало все депозиты у которых транзакции есть и они были типа "profit", и у которых нету) SELECT deposit.id, deposit.created_at, deposit.user_id, deposit.marketing_plan_id, deposit.invest_summ, deposit.is_ended, CASE WHEN COUNT(transaction) > 0 THEN SUM(transaction.summ) ELSE 0 END AS profit FROM deposits AS deposit LEFT JOIN transactions transaction ON deposit.id = transaction.deposit_id WHERE (transaction.type = 'profit') GROUP BY deposit.id ORDER BY deposit.id LIMIT 10;

Ну так в 10.1/10.2 то же поведение, если я правильно вижу.

Приветствую) Подскажите, пожалуйста, как написать условие что бы выбрало все депозиты у которых транзакции есть и они были типа "profit", и у которых нету) SELECT deposit.id, deposit.created_at, deposit.user_id, deposit.marketing_plan_id, deposit.invest_summ, deposit.is_ended, CASE WHEN COUNT(transaction) > 0 THEN SUM(transaction.summ) ELSE 0 END AS profit FROM deposits AS deposit LEFT JOIN transactions transaction ON deposit.id = transaction.deposit_id WHERE (transaction.type = 'profit') GROUP BY deposit.id ORDER BY deposit.id LIMIT 10;

Непонятно... можете переформулировать или показать пример?

Приветствую) Подскажите, пожалуйста, как написать условие что бы выбрало все депозиты у которых транзакции есть и они были типа "profit", и у которых нету) SELECT deposit.id, deposit.created_at, deposit.user_id, deposit.marketing_plan_id, deposit.invest_summ, deposit.is_ended, CASE WHEN COUNT(transaction) > 0 THEN SUM(transaction.summ) ELSE 0 END AS profit FROM deposits AS deposit LEFT JOIN transactions transaction ON deposit.id = transaction.deposit_id WHERE (transaction.type = 'profit') GROUP BY deposit.id ORDER BY deposit.id LIMIT 10;

... WHERE (transaction.type = 'profit' OR transaction.deposit_id ISNULL)

.deposit_id можно заменить на id например

без проблем. есть таблица депозитов, есть таблица транзакций. в транзакции заносится информация о зачисляемой прибыли с депозита. Необходимо выбрать все депозиты (без исключения) вместе с доходом по каждому

по некоторым депозитам, конечно же, может не быть записей в таблице транзакций

но их тоже нужно выбрать

Оборачивать в begin/commit нет смысла т.к. это делает команда -1

http://www.postgresql-archive.org/Rollback-on-include-error-in-psql-td5832192.html#a5832281

Всем привет, на таблице в которой не бывает больше 1000 строчек, индексы не нужны? Запросы обычно выбирают больше одной записи

... WHERE (transaction.type = 'profit' OR transaction.deposit_id ISNULL)

чет не сработало(

чет не сработало(

Не включились депозиты не имеющие транзакций?

да

да

может из-за лимита?

SELECT deposit.id, deposit.created_at, deposit.user_id, deposit.marketing_plan_id, deposit.invest_summ, deposit.is_ended, CASE WHEN COUNT(transaction) > 0 THEN SUM(transaction.summ) ELSE 0 END AS profit FROM deposits AS deposit LEFT JOIN transactions transaction ON deposit.id = transaction.deposit_id WHERE (transaction.type = 'profit' OR transaction.deposit_id IS NULL) GROUP BY deposit.id; вернул только депозит, у которого есть записи в транзакции(

SELECT deposit.id, deposit.created_at, deposit.user_id, deposit.marketing_plan_id, deposit.invest_summ, deposit.is_ended, CASE WHEN COUNT(transaction) > 0 THEN SUM(transaction.summ) ELSE 0 END AS profit FROM deposits AS deposit LEFT JOIN transactions transaction ON deposit.id = transaction.deposit_id WHERE (transaction.type = 'profit' OR transaction.deposit_id IS NULL) GROUP BY deposit.id; вернул только депозит, у которого есть записи в транзакции(

SELECT deposits.id, COALESCE(SUM(transactions.summ), 0) AS profit — и т.д. FROM deposits LEFT JOIN transactions ON deposits.id = transactions.deposit_id AND transactions.type = 'profit' GROUP BY deposits.id ORDER BY deposits.id

SELECT deposits.id, COALESCE(SUM(transactions.summ), 0) AS profit — и т.д. FROM deposits LEFT JOIN transactions ON deposits.id = transactions.deposit_id AND transactions.type = 'profit' GROUP BY deposits.id ORDER BY deposits.id

ПЕРФЕКТО спасибо большое :) сработало!

COALESCE вообще прелесть :)

http://www.postgresql-archive.org/Rollback-on-include-error-in-psql-td5832192.html#a5832281

Благодарю! Это то что нужно!