PostgreSQL 13 в production: vacuum, параллельные индексы и 20% на аналитике

PostgreSQL 13 GA вышел в сентябре прошлого года. Мы смотрели на него в бете ещё летом - тогда гоняли тест на слепке production и смотрели на дедупликацию B-tree и параллельный VACUUM. Бета - это бета, в production не катили. Прошло несколько месяцев, сообщество обкатало GA, вышли первые минорные патчи. В феврале решили, что пора - и перевели несколько клиентских баз с 11-й на 13-ю.

Рассказываем что получилось.

Откуда взялась прыжок через версию

На части клиентских DWH у нас до сих пор стояла PostgreSQL 11. Двенадцатую мы проходили мимо - планировали, но у клиентов не было подходящего окна для миграции, плюс 11-я на их нагрузке работала без жалоб. В итоге получилось удачно: прыгаем сразу на 13-ю, минуя 12-ю, и получаем разницу сразу двух поколений улучшений в одной миграции.

pg_upgrade --check на всех базах прошёл чисто. Фактический апгрейд делали по отработанной схеме: бэкап через pg_basebackup, схема отдельно через pg_dump --schema-only, апгрейд, vacuumdb --analyze-in-stages, наблюдение.

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

Главный сюрприз - агрегирующие запросы. На нескольких типичных запросах с GROUP BY по нескольким колонкам и SUM/COUNT по большим партиционированным таблицам планировщик PostgreSQL 13 стал выбирать заметно другие планы по сравнению с 11-й.

Конкретные цифры называть с осторожностью - нагрузка у каждого клиента своя, и прямое сравнение тут некорректно. Но диапазон 20-25% ускорения на тех запросах, которые мы отслеживали через pg_stat_statements, выглядит устойчиво - это не разовый выброс, а стабильная разница на недельном окне наблюдений.

Откуда это берётся:

• Улучшенный планировщик для партиционированных таблиц. В PostgreSQL 13 существенно ускорилась фаза планирования для таблиц с большим количеством партиций - планировщик отсекает ненужные партиции быстрее и строит более компактный план. На схемах с 40-60 месячными партициями это ощутимо.
• Параллельные индексные сканы. Несколько запросов, которые раньше шли через Seq Scan из-за того что планировщик не видел смысла в Index Scan на фоне дорогого shuffle, теперь используют параллельный Index Scan. Смотрится в EXPLAIN (ANALYZE, BUFFERS) - Workers Launched там там где раньше не было.
• Инкрементальная сортировка. В PostgreSQL 13 появилась инкрементальная сортировка - Incremental Sort в плане. Если запрос уже получает данные частично упорядоченными (из партиционирования по дате, например), планировщик умеет использовать этот порядок и досортировывать только в рамках групп. На запросах с ORDER BY created_at, category это срабатывает регулярно.

Vacuum - теперь реально параллельный

В бете мы уже смотрели на параллельный VACUUM, но с оговорками. В GA ситуация чище.

На OLTP-таблицах с активным bloat (там где много UPDATE на одних и тех же строках) ручной VACUUM (PARALLEL 4) работает ощутимо быстрее чем последовательный VACUUM в 11-й. На одной из баз с несколькими крупными таблицами процессинга - то, что раньше занимало около 40 минут в ночном окне обслуживания, теперь укладывается в 20-25.

Autovacuum параллелизм из коробки не использует - только явный VACUUM. Для основных таблиц мы добавили cron-задачу с параллельным VACUUM в ночное окно, max_parallel_maintenance_workers подняли до 4 и смотрим на I/O. Пока без проблем.

Одна вещь, которую стоит держать в голове: параллельный VACUUM с несколькими воркерами создаёт дополнительный I/O. Если дисковая подсистема уже под нагрузкой - лучше аккуратнее с числом workers и временем запуска.

Логическая репликация: что поменялось

PostgreSQL 13 расширил возможности логической репликации. Появилась поддержка двусторонней логической репликации между подписчиками - origin в публикации позволяет избежать петель при репликации. Также добавили pg_replication_slot_advance() для управления позицией слота без фактической репликации.

Для нас это интересно в контексте одной клиентской схемы, где DWH и OLTP живут в разных базах. Пока репликацию отдельных подмножеств строк делаем через ETL с явной фильтрацией - в логической репликации row-level фильтрация на уровне публикации не поддерживается, так что пока это остаётся задачей ETL-слоя. Пункт в бэклоге.

Партиционирование: ещё один шаг вперёд

После PostgreSQL 12, где партиционирование наконец стало вести себя предсказуемо, 13-я версия добавила несколько точечных улучшений:

• Ускоренный partition pruning во время выполнения - планировщик лучше работает с неконстантными параметрами, то есть с теми случаями, где параметр становится известен только в runtime.
• Возможность ATTACH PARTITION быстрее - уменьшили блокировки при присоединении новой партиции к существующей таблице. На живой системе с высокой нагрузкой это было узким местом.

Второй пункт практически сразу пригодился: у одного клиента ежемесячное добавление партиции вызывало кратковременные замедления. Не катастрофу, но BI-дашборды на этот момент подвисали. Сейчас добавление новой партиции проходит тише.

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

Честно: один запрос стал чуть хуже. Планировщик выбрал другой join-метод на крупной аналитической выборке - hash join вместо merge join, что привело к большему расходу памяти и чуть медленнее на 15%. Не катастрофа, решилось через pg_hint_plan, но показывает что слепо доверять планировщику не стоит - первые пару недель после апгрейда важно мониторить pg_stat_statements и сравнивать с baseline.

Где сейчас

Три базы уже две недели на PostgreSQL 13, без инцидентов. Ещё две в очереди - там более сложные зависимости между схемами и нужно поширше окно для работ. Планируем в марте.

Общее ощущение от 13-й: это заметный шаг для аналитических нагрузок. Не маркетинговый - реальный прирост на агрегирующих запросах, параллельный VACUUM в обслуживании, инкрементальная сортировка в планах. Если вы на 11-й или 12-й и у вас DWH с партиционированием - смотреть на 13-ю имеет смысл уже сейчас.