PostgreSQL 18 и async I/O: у кого в проде, есть реальный прирост?

[timur12]

Накатил 18.3 на стейдж (переезжали с 16.4), ядро 6.8, выставил io_method = io_uring. Холодные seq scan по таблице на 200 гигов ускорились примерно в 1.7 раза, vacuum заметно бодрее. Но на обычном OLTP профиле разницы ноль, что в общем логично, всё читается из shared_buffers. Из приятного ещё uuidv7() из коробки, выкинули расширение, и skip scan по составным индексам спас пару кривых запросов без переделки индексов.

Кто уже держит 18 в проде под реальной нагрузкой, какие подводные? Синтетику я и сам могу погонять, интересует именно прод.

[regexlover]

у нас на проде 13 доживает последний год поддержки, так что смотрю на вас как на космонавтов

[coldpanic]

Мы на 18 с января, три кластера, самый жирный 2.5 ТБ. Пара моментов, которые в маркетинг не попали.

Async I/O пока только про чтение: seq scan, bitmap heap scan, vacuum. Запись и index scan живут по-старому, поэтому OLTP и не ускоряется, это ожидаемо. Дефолт кстати io_method = worker с тремя воркерами, io_uring надо включать руками, и в кубере с дефолтным seccomp профилем io_uring может быть просто запрещён, у нас на одном кластере ловили EPERM при старте, пока не поправили профиль.

И главная подстава апгрейда вообще не про AIO: в 18 initdb по умолчанию включает чексуммы данных. Если старый кластер был без них, pg_upgrade обламывается. Либо initdb --no-data-checksums для нового, либо сначала включай чексуммы на старом через pg_checksums.

По цифрам: vacuum на таблице в 800 гигов стал быстрее процентов на 40, прогрев холодной реплики тоже ощутимо приятнее. На горячем кеше всё то же самое, чудес нет.

[seniorsamurai]

в 18 initdb по умолчанию включает чексуммы данных

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

[smith_zhenya]

@coldpanic, io_uring на проде это смело. в гугле его у себя отключили ещё в 23м из-за дыр, и с тех пор CVE по нему капают стабильно. для базы с персональными данными я бы сто раз подумал, безопасники такое не согласуют

[envoy69]

в гугле его у себя отключили ещё в 23м из-за дыр

аргумент трёхлетней давности. в ядрах 6.6+ большую часть проблемных мест перекрыли, плюс никто не заставляет: режим worker остаётся дефолтом и даёт большую часть профита без io_uring вообще. параноикам worker, остальным io_uring после своих тестов. а вот у кого по требованиям регуляторов сертифицированный Postgres Pro или Tantor, тем 18 ветку ещё ждать, пока вендоры подтянутся, у них база пока на 16-17