Попросил постгрес отсортировать три строки. Результат: https://30.rkn.gov.ru/ http://s31740.tistory.com/ https://31.rkn.gov.ru/ Предлагаю вам догадаться, как это работает. Это весело.

Вообще концепция shared buffers мне как раньше казалась ебанутой, так и сейчас кажется. Эти кеши/буферы работают примерно так же, как и линупсячьи. А может ли существовать идея гениальнее, чем продублировать кеш в одной и той же оперативной памяти? Я спрашивал у дядей DBA'ев, нахуя они нужны — те что-то блеют про прирост в производительности в 20%, если засрать буферами всю память. Охуенно.

Отвечаю самому себе на #793J1I: надо было ебануть bgwriter_lru_maxpages = 0 в постгресе.

> The database was created using collation version 2.31, but the operating system provides version 2.36. С превеликим удовольствием узнал, что PostgreSQL из коробки поражен чумой XXI века юникодом. В случае выполнения определенных условий перед каждым обновлением libc надо останавливать к хуям базу, а после него — делать REINDEX, а иначе индексы начнут показывать погоду на марсе.

=> SELECT CASE NULL WHEN NULL THEN 'null' ELSE 'not null' END; not null

# SELECT int8range(1, 2, '[]'); int8range ----------- [1,3) да ебаное ты говно

SKIP LOCKED работает не совсем ожидаемо, если блокируются строки из нескольких таблиц. То есть если сделать SELECT ... FOR UPDATE OF table1, table2 SKIP LOCKED, то строку в table1 он заблокирует без ожидания, а вот на table2 — встанет. Или ебнетеся с дедлоком, если нужна строка в table2 уже заблокирована и тоже ждет.

pg_stat_statements заебись.

> То есть номера идут без серьезных пропусков и по нарастающей. > 5. После более внимательного изучения устройства баз данных (а мы исходим из того, что регистры Минздрава работают под управлением свободно распространяемой системы управления базами данных PostgreSQL, как указано в отчете о внедрении информационной системы) мы склонны считать, что номера из базы не удаляются и не присваиваются повторно другим людям. Редкое зрелище: тупорылый уебок, которому хочется разбить ебало, не понимает, как работают сиквенсы, и откуда в них дырки; при этом это не пидорас-айтишник, а пидорас-журналист.

Че-то мне совсем разонравился постгрес. Планировщик — ебаное говно, которое расчитано на работу неоптимизированных запросов в неоптимизированной базе, которая хотя бы большими кусками помещается в оперативную память. Короче говоря — в распиздяйском окружении. А в условии ограниченных ресурсов все плохо. В итоге у меня на весь инстанс глобально стоит: enable_bitmapscan = off enable_hashjoin = off enable_mergejoin = off — просто чтобы избавиться от появляющихся зависших запросов, из-за которых пользователи отфутболиваются по таймауту. Простой пример: изобретаем мы электронную почту. Делаем таблицу messages (user_id, date, ...) Делаем индекс для нее по (user_id, date DESC) Каждому пользователю показываем 50 последних писем при помощи WHERE user_id = ... ORDER BY date DESC. Ничего фантастического, самое обычное поведение самого обычного приложения. Все работает очень быстро: делается index scan и nested loop 50 раз. Но только покудова мы одновременно не джоиним messages с какой-нибудь второстепенной хуетой. Тут планировщик начинает делать bitmap index scan, потом hash/merge join, а потом sort by date DESC. Беда в том, что писем у пользователя может быть 100 штук, а может быть 100 000 штук. Bitmap index scan в этом случае выбирает целый миллион, потом все это «быстро» и «эффективно» (как задумывалось планировщиком) джоинится, потом фильтруется лишнее (до 100 000 строк), потом сортируется, потом берутся верхние 50 писем. В результате пользователь со ста тысячами писем не может зайти в свой почтовый ящик вообще: он видит только nginx gateway timeout. И ситуации подобные этой возникают постоянно. Иногда запрос работает хорошо, но только меняется аргумент в условии — все идет пиздой. Например, планировщик, которого попросили письма двухнедельной давности, может решить, что теперь-то эффективнее делать bitmap index scan — и все по-новой. Обычная статистика не помогает, потому что, как я уже говорил, писем может быть и 100, и 100 000. Но в среднем — голубцы. CREATE STATISTICS еще не опробовал. Надеюсь, конечно, что поможет, но едва ли это очевидное решение. Хуй, блять, знает, какие исходники надо ковырять, чтобы сделать планировщик ПЕССИМЕСТИЧНЕЕ. Чтобы, блять, если в теории возможно, что план по выборке 50 обоссаных писем может закончится бедой — он не пользовался этим планом. Хинтов в постгресе нет. Есть возможность отключать отдельные виды тактик на время сессии, и, по-моему, даже во время транзакции. Вообще, все это хуйня, и через «еб твою мать!» с ней можно справиться. Но основной тренд очень расстраивает.

Давайте переименуем pg_xlog в pg_wal, чтобы дебичи перестали чистить диск от «каких-то логов», а у нормальных людей все скрипты сломались к хуям.

как же хуево жить в мире где антиджоины тормозят

https://europepmc.org/article/med/32477687#free-full-text что это блядь за вольтрон-хуесос такой

til pg_restore -j вся жизнь коту под хвост

https://gist.github.com/dmitry-naumenko/cef3456d6775ca0f377375af38c9e66f#file-get_unused_indexes_en-sql бля

На какие грабли можно напороться, раздавая timestampz вместо timestamp налево и направо?

Придумайте, почему я не хочу created_at timestamptz NOT NULL DEFAULT statement_timestamp() Я, конечно, хотел сделать now(), как и все. Но потом понял, в случае параллельных транзакций с блокировками одного ресурса у меня может случиться TIME PARADOX.

еб твою мать на хуй, на postgresql.org/docs редизайн закопуйте, это начало конца

http://komar.in/ru/быстрое-агрегирование-в-postgresql найдите там ошибки за меня, лень читать

уебал в конфиге чекпоинты как хорошо-то стало сразу