PostgreSQL 18 на проде: io_uring, воркеры и реальные цифры после трёх месяцев

[Austkin]

Дозрели до апгрейда 16.6 → 18.2 ещё в феврале, сейчас уже 18.3, статистика накопилась — делюсь.

Сетап: своё железо, Ubuntu 24.04, ядро 6.8, NVMe в RAID10, база 1.4 ТБ, нагрузка OLTP плюс ночная аналитика. Апгрейд через pg_upgrade --link, даунтайм 6 минут вместе с прогоном vacuumdb --analyze-in-stages.

Главное в 18-ке — асинхронный ввод-вывод. Проверили оба режима:

- io_method = worker (дефолт, 3 воркера): ночной seq scan по таблице ивентов на 380 ГБ ускорился с 41 до 19 минут. Просто после апгрейда, без единой правки запросов.
- io_method = io_uring: ещё минус 15-20% на холодных чтениях, но на горячем кэше разницы с worker практически нет.

Не забудьте про effective_io_concurrency — дефолт в 18-ке подняли до 16, но под NVMe имеет смысл крутить выше, мы остановились на 64.

Отдельно про uuidv7(): перевели новые таблицы с v4. Индекс на 140 млн строк стал компактнее примерно на четверть, скорость вставки выросла на треть — сказывается локальность записи в b-tree.

Из неочевидного: в контейнерах io_uring может быть просто запрещён seccomp-профилем, проверьте это до того, как удивляться отсутствию эффекта. И классика жанра: новый glibc на новой убунте — обязательный REINDEX всех текстовых индексов, если вы не на ICU.

Кто ещё переехал — какие цифры у вас?

[lonelygoblin]

Про uuidv7 поддержу цифрами: на вставке в таблицу заказов p99 упал с 14 до 9 мс после ухода с v4, фрагментация индекса перестала расти. Но имейте в виду: v7 содержит таймстемп, по публичному идентификатору можно вычислить время создания записи. Для внутренних ключей — отлично, наружу мы отдаём отдельный непрозрачный ID.

[seniorsamurai]

Прыгали с 15.8 на 18.2 месяц назад: pgvector 0.8 собрался и завёлся без вопросов, pg_partman тоже, главное — обновить сами расширения до версий с поддержкой 18-ки до запуска pg_upgrade. Отвалился только старый самописный модуль на C, пришлось править под новые хуки. Мажорный прыжок через две версии — штатная история, бояться нечего, репетируйте на реплике.

И про энтерпрайз-специфику СНГ: кто сидит на Postgres Pro из-за сертификации — там в ветке Enterprise асинхронный ввод-вывод свой и появился раньше ванильного, но настройки несовместимы с ванильными, тюнинг придётся делать заново.

[kickmybox]

Только давайте честно: на чистом OLTP с hit ratio 99% весь этот AIO даёт около нуля, что вы сами и подтверждаете. Для меня главные фичи 18-ки другие — skip scan по составным индексам (выкинули три «дублирующих» индекса, которые держали только ради запросов без ведущей колонки) и виртуальные генерируемые колонки. Вот это реальная экономия места и времени, а не красивые графики seq scan.

[shane666]

Подтверждаю про контейнеры. У нас кластер в K8s, дефолтный профиль containerd режет io_uring-сисколлы ещё со времён прошлогодней волны CVE. Городить кастомный seccomp ради базы не стали — оставили io_method = worker и подняли io_workers до 8 на 32 ядрах. На нашем профиле нагрузки разница с io_uring в пределах 5%, овчинка выделки не стоит.

[burnedblueteam]

А как у 18.x с расширениями? Конкретно интересуют pg_partman и pgvector — хотим прыгать с 15-й сразу на 18, но боязно, простой больше десяти минут позволить не можем.