PostgreSQL 19 стабилизирует планы запросов

В мартовском коммитфесте PostgreSQL 19 приняли расширение pg_plan_advice, которое позволяет зафиксировать решения планировщика для конкретного запроса. Это важно, потому что нестабильные планы остаются одной из главных причин скачков производительности после обновления статистики или версии. Планировщик запросов — это компонент СУБД, который выбирает способ выполнения SQL-оператора на основе статистики таблиц и доступных индексов. Когда статистика меняется, план может перестроиться, и запрос внезапно начинает работать медленнее. Одновременно отменили несколько крупных фич, которые уже успели попасть в основную ветку. Инженерам стоит оценить, насколько критична для них фиксация планов и не потеряны ли ожидаемые возможности. Если проект зависит от предсказуемой производительности и частых обновлений статистики, то инструмент фиксации планов может снизить риски инцидентов. В противном случае отмена фич может заставить пересмотреть сроки миграции.

Отменённые возможности

До заморозки кода в 19-ю версию успели включить несколько заметных изменений, которые позже откатили. Среди них слияние и разделение секций, GROUP BY ALL, поддержка всех форматов pg_dump в pg_dumpall, SQL/PGQ, обновление и удаление по прикладному времени SQL:2011, встроенные функции для DDL ролей и баз, а также переключение контрольных сумм без остановки кластера. Слияние и разделение секций упростило бы управление большими таблицами, где данные делятся по диапазонам или спискам значений. GROUP BY ALL сократило бы написание отчётов, избавляя от явного перечисления всех группируемых столбцов. SQL/PGQ добавил бы поддержку графовых запросов внутри реляционной модели, что важно при миграции с Oracle. Обновление и удаление по прикладному времени позволило бы работать с историческими данными без дополнительных триггеров. Отмена этих фич означает, что часть планов миграции придётся пересматривать. Если команда рассчитывала на автоматическое слияние секций или на GROUP BY ALL для сокращения кода отчётов, то в 19-й версии этих инструментов не будет. На момент подготовки статьи дата выпуска назначена на 29 октября, поэтому список ревертов ещё может вырасти. Перед обновлением стоит составить реестр запросов и скриптов, которые опираются на отменённые возможности, и оценить трудозатраты на их переработку.

Новое расширение для стабилизации планов

Основное нововведение коммитфеста — расширение pg_plan_advice. Оно не создаёт объектов в базе и загружается одной командой LOAD. После загрузки EXPLAIN получает параметр plan_advice, который показывает ключевые решения планировщика в компактном мини-языке: SEQ_SCAN, GATHER, NO_GATHER и так далее. Планировщик оценивает стоимость каждого варианта выполнения и выбирает наименьшую. Полученные советы можно записать в параметр pg_plan_advice.advice. При следующем EXPLAIN планировщик отмечает, какие из них приняты. Это позволяет зафиксировать план, который сейчас работает стабильно, и защитить его от изменений статистики или версии. Инструмент не заменяет hints в полном смысле, но даёт более явный и воспроизводимый способ влияния на план. Для команд, которые уже сталкивались с регрессом после ANALYZE, такое расширение снижает вероятность внезапных просадок. При этом оно не требует изменения кода приложения и проще сертифицируется, чем патчи ядра. Если нестабильность планов уже приводит к инцидентам SLA, стоит протестировать расширение на копии продакшена. В остальных случаях можно обойтись мониторингом и ручной настройкой.

Изменения планировщика

В мартовском коммитфесте также улучшили оценку кардинальности для NOT IN с NULL, добавили антисоединения для NOT IN-подзапросов и внешних левых соединений. Кардинальность — это оценка количества строк, которые вернёт оператор. Появилась расширенная статистика по виртуальным вычисляемым столбцам и импорт статистики через postgres_fdw. JIT-компиляцию по умолчанию отключили. Эти правки снижают вероятность плохих планов в запросах с NOT IN и внешними соединениями. Антисоединение позволяет планировщику эффективнее обрабатывать случаи, когда нужно исключить строки, присутствующие в другой таблице. Однако отключение JIT по умолчанию потребует явной настройки для тяжёлых аналитических нагрузок. JIT ускоряет выполнение сложных выражений за счёт компиляции в машинный код, и его отключение по умолчанию защищает OLTP-системы от лишних накладных расходов. Инженерам, которые полагались на автоматическое включение JIT, придётся добавить параметр в конфигурацию после обновления. Перед миграцией стоит измерить долю запросов, которые выигрывают от JIT, и принять решение о включении.

Что учитывать при миграции в российском контуре

В российских инфраструктурах часто используют жёсткие политики обновления и собственные сборки PostgreSQL. Расширение pg_plan_advice требует загрузки модуля и не создаёт объектов, поэтому его проще сертифицировать, чем патчи ядра. Однако отмена секционного DDL и SQL/PGQ может затронуть проекты, где планировалась миграция с Oracle или сложные ETL-процессы. Перед обновлением стоит проверить, есть ли в текущих запросах зависимость от отменённых фич и насколько часто планы меняются после ANALYZE. Если нестабильность планов уже приводит к инцидентам, pg_plan_advice даёт практичный способ снизить риски без перехода на коммерческие решения. В остальных случаях можно дождаться финального списка изменений ближе к октябрю. Командам, которые ценят предсказуемость выше новых синтаксических возможностей, имеет смысл включить расширение уже на этапе тестирования. Тем, кто ждал упрощения работы с секциями или графовыми запросами, придётся искать обходные пути или отложить обновление.

Источник

Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: PostgreSQL 19 стабилизирует планы запросов.

Курс по теме — Каталог курсов Школы Больших Данных