Три месяца на PostgreSQL 18 в проде: где async I/O реально стреляет, а где маркетинг

[elixir1337]

Обещал коллегам по цеху отписаться — выполняю. В марте перевели основной кластер с 16.4 на 18.2, шли в первую очередь за асинхронным вводом-выводом.

Замеры на наших задачах (аналитические выборки по таблицам 200-800 ГБ, NVMe, страничный кэш холодный): io_method=worker даёт ускорение seq scan примерно в 1.6 раза против старого синхронного чтения, io_method=io_uring — до 2.1x на самых тяжёлых проходах. На OLTP-профиле разницы практически нет, что ожидаемо — горячие данные и так в shared_buffers.

Отдельный кайф, о котором мало говорят: pg_upgrade теперь переносит статистику планировщика. Раньше после мажорного апгрейда был час деградации, пока ANALYZE прожуёт базу, в этот раз — переключились и поехали.

Из граблей: io_uring завести оказалось не везде тривиально, ниже отвечу почему. И вопрос к коллективному разуму: кто-нибудь уже гонял skip scan по составным индексам на реальных данных?

[proxmox10]

Дополню про io_uring, мы об это убились первыми: дефолтный seccomp-профиль Docker режет io_uring-сисколы — их выкинули из разрешённых после серии уязвимостей в ядре. Так что в контейнерах либо тащите кастомный seccomp-профиль (и согласовывайте с безопасниками, удачи), либо оставляйте io_method=worker. Мы на k8s померили: worker отстаёт от io_uring процентов на десять, решили, что овчинка выделки не стоит, живём на worker.

[rawgoblin]

@elixir1337, Skip scan — тихая звезда релиза, расскажу на нашем кейсе. Есть индекс (region_id, created_at), исторически куча запросов фильтрует только по created_at. До 18-й планировщик либо уходил в seq scan, либо мы держали второй индекс чисто по дате — лишние 60 ГБ и тормоза на вставке. Теперь btree skip scan перебирает значения первой колонки сам: запрос, который шёл 11 секунд seq scan-ом, выполняется за 180 мс по существующему индексу.

Важная оговорка: это работает, потому что у нас в первой колонке 14 регионов. Skip scan выигрывает при низкой кардинальности ведущей колонки. Коллеги попробовали то же самое с user_id первым полем — естественно, никакого выигрыша, там сотни тысяч значений.

[mattyoh]

Порадуюсь за вас и позанудствую с другой стороны баррикад: мы пока на 16 и сидим ровно. Во-первых, у нас требование реестра — ждём, когда восемнадцатая ветка доедет до сборок Postgres Pro, со своими патчами они не торопятся. Во-вторых, рядом живёт 1С, а там своя камасутра совместимости. В-третьих, старое правило: на мажор раньше минорных .1-.2 в прод не ходим, и 18.0 с его ноябрьскими фиксами это правило в очередной раз подтвердил. Через годик догоним.

[puto]

@elixir1337, А мы апгрейдились ради скучной на первый взгляд вещи — uuidv7(). Перевели новые таблицы с рандомных v4 на v7 (нативная функция, без расширений) — и btree по первичному ключу перестал пухнуть от случайных вставок, WAL на вставочной нагрузке упал примерно на треть, кэш-хит по индексу вырос. Пять лет страданий с v4, а решение оказалось одной функцией в ядре.