PostgreSQL 18 GA: подводим итоги нашего тестирования с beta и RC

PostgreSQL Global Development Group выпустила PostgreSQL 18 GA. Мы следили за этим релизом с июля - сначала тестировали beta на синтетической нагрузке, потом гоняли RC на реальных клиентских схемах. Сейчас самое время посмотреть, что из наших наблюдений подтвердилось, где реальность оказалась лучше ожиданий, а где - чуть скромнее.

Что подтвердилось полностью

Async I/O работает так, как обещали. На нагрузках, где рабочий набор данных не умещается в shared_buffers и диск реально задействован, прирост throughput стабильный и воспроизводимый. На наших стендах это было 18-20% при io_method=io_uring относительно PG17 - и в GA эта цифра никуда не делась. Важнее другое: хвосты latency ведут себя лучше именно потому, что сервер перестаёт блокироваться на I/O-ожидании. p99 снизился заметно сильнее, чем медиана - это хорошо видно при сравнении гистограмм pgbench.

io_uring стабилен. В бете у нас был один необъяснённый краш при стрессовом тесте с высоким concurrency - сообщили в трекер, но воспроизвести стабильно не смогли. В RC той проблемы уже не было, в GA - тем более. Для ядер 6.1+ с io_uring без ограничений seccomp это рабочий путь, а не экспериментальный.

Регрессия с PgBouncer закрыта. В RC мы поймали зависание при transaction mode и высоком concurrency - оказалась проблема совместимости с PgBouncer 1.21. В GA это поведение подправлено на стороне Postgres, плюс актуальный PgBouncer закрыл это со своей стороны раньше. Кто обновился до 1.23+ - скорее всего уже не столкнётся.

Где оказалось лучше ожиданий

Параллельный query execution. Мы заходили на тестирование с фокусом на async I/O, а улучшения в parallel query cost estimation оказались приятным бонусом. На аналитических профилях несколько тяжёлых запросов с hash join по большим таблицам получили лучший план без каких-либо хинтов - просто планировщик стал точнее оценивать стоимость параллельных операций. Для OLTP это незаметно, но для batch-обработки и ночных ETL - ощутимо.

Миграция через pg_upgrade прошла чище, чем мы ожидали. На трёх клиентских профилях апгрейд с PG17 на PG18 занял сопоставимое время и не дал сюрпризов. Основной объём работы - это инвентаризация расширений и осознанный выбор параметра io_method после апгрейда. Сам pg_upgrade отработал штатно.

pg_stat_io в GA стал информативнее. Этот системный вид появился в PG16, в 18-й его расширили. Теперь там значительно удобнее смотреть на реальное поведение I/O по backend-типам - и при диагностике нагрузки это экономит время.

Где оказалось скромнее ожиданий

Прирост на умеренной нагрузке - почти ноль. Это мы писали ещё в июле: async I/O раскрывается только тогда, когда диск является реальным бутылочным горлом. Если рабочий набор влезает в shared_buffers или нагрузка по concurrency невысокая - разница с PG17 в пределах погрешности. Заказчики с небольшими базами и хорошим запасом памяти не почувствуют почти ничего.

Баг с pg_stat_statements и DDL-запросами. В RC мы нашли странную нормализацию для CREATE TABLE ... LIKE с несколькими параметрами - запросы попадали в разные строки вместо одной. В GA это не исправили - баг есть в трекере, но не попал в финальный релиз. Для команд, у которых мониторинг строится на агрегатах из pg_stat_statements, это может дать шум в дашбордах. Лечится фильтрацией, но неприятно.

Расширения - по-прежнему нужна проверка. К моменту GA большинство популярных расширений пересобрали под 18-ю - но не все. Exotica типа специфических шардинговых расширений может ещё не иметь совместимой версии. Инвентаризация перед апгрейдом обязательна.

Конфигурация: что нужно сделать сразу после апгрейда

Коротко по параметрам, которые требуют осознанного выбора в PG18 - их нет в старых конфигах, а дефолты не всегда оптимальны:

• io_method - новый параметр. Дефолт worker работает корректно везде. Если ядро 6.1+ и io_uring не заблокирован - имеет смысл переключить на io_uring после нагрузочного тестирования.
• max_io_concurrency - дефолт 16. На быстром NVMe стоит попробовать 32; эффект зависит от железа.
• effective_io_concurrency - в 18-й семантика изменилась, это теперь hint для планировщика о возможностях железа, а не ограничитель. Если было выставлено под старую логику - пересмотреть.

Когда планируем первую продакшн-миграцию

Для OLTP-нагрузок с реальным I/O-давлением - планируем первый production-апгрейд в январе на одном из клиентов. Профиль подходящий: рабочий набор не влезает в RAM, активная запись, NVMe, ядро 6.1. RC там уже прогоняли на изолированном стенде с реальной копией данных - поведение было стабильным. После GA выждем пару недель, посмотрим на первые патч-нот и отчёты сообщества о production-инцидентах - и пойдём.

Для аналитических нагрузок (ETL, DWH) - чуть позже, там ценность в улучшениях планировщика, а не в async I/O, и это требует более тщательного тестирования конкретных запросов. Плюс в этом контуре у нас расширения, которые ещё не все дотянулись до PG18.

Для КИИ-контуров с требованием сертифицированного дистрибутива - ждём Tantor SE 18 в реестре ФСТЭК. Tantor получил сертификат в ноябре, и для этих заказчиков именно сертифицированная сборка закладывается в целевую архитектуру на 2026 год.

В целом 18-я - хороший релиз без сюрпризов. Полгода тестирования дали достаточно уверенности.