Завел pg_strom на Nvidia Tesla K40c. Придумайте смешных агрегаций, пока я качаю 70 гигабайт базы.

Умеет понимать, что хотят от WHERE NOT EXISTS (SELECT 1 FROM ...) и перепланировать по своему вкусу. Охуеть можно.

Никогда не используйте CREATE INDEX CONCURRENTLY. Оно вам молча насоздает паленых индексов, которые молча ни хуя не работают.

til CREATE INDEX CONCURRENTLY о сколько нам открытий чюдных

какую тулзу натравить на пж чтобы получить красивую картинку связей таблиц?

Совет дня: запуская написанный жопой aggregate-запрос на большой базе — посматривайте в watch du -h /var/lib/postgresql/*/main/base/pgsql_tmp/. Особенно если вы делаете это на боевой базе (ну что может случиться от безобидного селекта?). Особенно если там мало свободного места.

с приходом упсерта делать нелепые уровни нормализации стало просто как никогда

Это просто ОХУИТЕЛЬНО. ЛЮБОЕ действие над матвьюхой заблокирует ее на чтение на время транзакции, даже если это RENAME TO. Никогда не пользуйтесь матвьюхами в постгресе, это говно.

При миграции путем BEGIN DROP MATERIALIZED VIEW ..; CREATE MATERIALIZED VIEW ...; COMMIT постгрес блокирует к хуям вьюху на чтение еще во время выполнения транзакций. Не пользуйтесь постгресовыми матвьюхами, их делали жопой.

«Меняй кучу строк в транзакции в несколько потоков и не уебись в дедлок» (игра для всей семьи)

впервые в жизни заюзал упсерт

не, я, конечно, видел, что есть какое-то там слово CONCURRENTLY но блядь, чтобы при обычном рефреше матвьюха НА ЧТЕНИЕ лочилась ну как можно было сделать так хуево-то, Господи

Ебаный autovacuum ни хуя не пылесосит. Нажмешь вручную — и размер базы перестает расти. grep vacuum /etc/postgresql/9.6/main/postgresql.conf autovacuum = on Че ему еще нажать, чтобы почаще пылесосил? Там десятка два этих опций, ни хуя не понятно.

Массовое удаление из большой базы на полчаса сломало планировщик. У простого джоина трех таблиц planning time — 50ms, execution time 0.5ms. Загадошно, блядь.

ура, словил баг в постгресе 100% CPU на BIND, нихуя не помогает ебаные блядь калмылки

http://blog.sagemath.com/2017/02/09/rethinkdb-vs-postgres.html //читать не нужно чувак повёлся на хайп и кровью анальной жёпы внедрил себе в анус^Wпродакшен rethinkdb, через пару месяцев оно благополучно заявило о закрытии. и до него вдруг дошло что в postgresql есть notify и значить rethinkdb ненужно. обычная история, но интересный момент в том что первый раз вижу чтобы notify работал в продакшене.

Совет дня: никогда не пихайте NULL там, где можно без нарушения логики сделать NOT NULL DEFAULT 0/1970-01-01 00:00:00/'' Особенно если планируется потом индекс сверху городить.

Это пиздец, ребята. Никогда не пользуйтесь pg advisory locks, это не работает. Локи, которые не релизятся даже после прибития всех соединений. Только рестарт сервера помогает. Это как вообще, блядь?

Если вы всю жизнь лочили записи в постгресе по-разному, а с advisory locks дела не имели, а тут вдруг пришлось — обратите внимание, что обычная pg_advisory_lock лочит в рамках всей сессии, а не транзакции как обычно. А то можно охуеть головой и угробить несколько часов на дебаг. У меня, вон, получилось.

Отвечаю на свой вопрос. Пусть есть две транзакции, которые выполняются одновременно: BEGIN; INSERT INTO t (id) VALUES (1); SELECT pg_sleep(10); /* рейс кондишон */ COMMIT; И на id у нас unique constraint. Че произойдет: одна из транзакций сразу прочухает, что произошел конфликт, и станет ЖДАТЬ, когда вторая транзакция завершится. Если во второй транзакции пройдет COMMIT, то ждущая повалится с "duplicate key value violates unique constraint". Если же вторая транзакция вместо COMMIT сделает ROLLBACK, то первая перестанет ждать и пойдет дальше. Если же у нас инсертов много и они проходят в интересном порядке, то одна из транзакций свалится на "deadlock detected", а вторая пройдет. В общем-то все очень просто и очевидно. Но смутные сомненья, они такие. Неочевидным был только то, ебнется ли инсерт сразу. Оказалось, что будет ждать завершения другой транзакции, и только тогда ебнется со спокойной совестью.