Совет дня: запуская написанный жопой 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, нихуя не помогает ебаные блядь калмылки

Совет дня: никогда не пихайте 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", а вторая пройдет. В общем-то все очень просто и очевидно. Но смутные сомненья, они такие. Неочевидным был только то, ебнется ли инсерт сразу. Оказалось, что будет ждать завершения другой транзакции, и только тогда ебнется со спокойной совестью.

Пришли юзеры, наподписывались на хуйню. Вкорячил pg_try_advisory_lock, включил второй воркер. Отличная платформа для обкатки АРХИТЕКТУР.

Совет дня: не используй NULLS FIRST/LAST, когда можно COALESCE.

HASH ANTI JOIN как это работает, сука

добавить nullable smallint — 0.0015s добавить not null boolean default false — 282.3495s надо начинать исходники читать, а то я никогда не пойму, как эта хуйня работает

Бля, реально? Я не могу написать CREATE VIEW table.* и должен каждый раз при изменении исходной таблицы менять вьюху? С какого хуя, гайс?

Совет дня: если вам нужно LIKE '%хуита', а думать лень — ебаните индекс по reverse()