Производительность
Перепланирование запросов
16
Авторские права
© Postgres Professional, 2023–2026
Авторы: Алексей Береснев, Илья Баштанов, Павел Толмачев, Игорь
Гнатюк
Фото: Олег Бартунов (монастырь Пху и пик Бхрикути, Непал)
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
edu@postgrespro.ru
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Проблема и решение
Механизм работы
Условия перепланирования
Особенности реализации
Как правило, ошибки при планировании вызваны некорректной оценкой
кардинальности. Частая причина этого — неактуальная статистика
планировщика. Например, в OLTP-системах это может быть вызвано
устареванием статистики из-за часто изменяющихся данных,
неравномерным распределением или использованием подготовленных
запросов с параметрами (когда оптимизатор переключается на общий
план выполнения).
Если в процессе выполнения запроса обнаруживается, что показатели
значительно отличаются от ожидаемых, можно прервать выполнение и
произвести планирование повторно, воспользовавшись накопленными
в процессе выполнения дополнительными данными. Для этого
необходимо настроить желаемые условия перепланирования.
Перепланирование запросов в реальном времени особенно актуально
для тяжелых аналитических OLAP-запросов, для которых накладные
расходы на перепланирование будут относительно невелики.
Перепланирование можно использовать и для проблемных OLTP-
запросов.
3
Проблема и решение
Ошибки в оценке кардинальности
статистика устаревает из-за частых изменений данных
неравномерное распределение данных
параметризованные запросы и подготовленные операторы
При сильном несоответствии
выполнение прерывается
запрос планируется повторно с учетом полученных данных
Классы запросов
тяжелые аналитические OLAP-запросы
проблемные OLTP-запросы
5
Механизм работы
дерево
запроса
дерево
запроса
план
запроса
планирование
разбор переписывание
результат
исполнение
сработало
условие?
текст
запроса
кардинальность
узлов
только
для текущего
запроса
обычная
статистика
нет
да
вложенная транзакция
Перепланирование запросов встраивается в стандартную схему работы
планировщика Postgres Pro.
Если во время или после выполнения узла плана выполняется условие
перепланирования, запрос прерывается и актуальная кардинальность
узлов плана (а также дополнительная служебная информация)
сохраняются. Далее запускается процесс перепланирования, который
может использовать сохраненную кардинальность для получения
лучшего плана.
Кардинальность сохраняется только для тех узлов плана, в которых
реальная кардинальность оказалась больше плановой. Эта
информация хранится только в процессе перепланирования текущего
запроса. Если запрос выполняется часто, новый план можно запомнить
с помощью расширения pgpro_multiplan (рассматривается в теме
«Сохранение планов запросов»).
Перед попыткой планирования создается вложенная транзакция. При
срабатывании условия перепланирования эта транзакция обрывается
и начинается новая.
Все выбранные планы для всех попыток перепланирования
сохраняются в журнале сообщений сервера.
В любом случае, перепланирование необходимо использовать
аккуратно и проверять его влияние на систему в целом.
Подробности можно прочитать в статье Алены Рыбакиной и Андрея
По умолчанию перепланирование запросов отключено. Для включения
достаточно установить конфигурационный параметр replan_enable
и настроить условия перепланирования, или триггеры (не имеющие
отношения к обычным триггерам базы данных).
В Postgres Pro Enterprise 16 перепланирование срабатывает в трех
следующих случаях:
●
По времени выполнения.
Запрос выполняется дольше, чем указано в параметре
replan_query_execution_time.
●
По ошибке оценки кардинальности после выполнения узла.
После выполнения узла плана количество обработанных строк
превысило число, ожидаемое планировщиком, умноженное на
значение replan_overrun_limit.
●
По перерасходу памяти и ошибке оценки кардинальности
во время выполнения узла.
Во время выполнения узла плана потребление памяти рабочим
процессом превысило значение replan_memory_limit, а количество
уже обработанных строк превысило число, ожидаемое
планировщиком, умноженное на значение replan_overrun_limit.
Перепланирование можно инициировать и вручную с помощью функции
replan_signal.
6
Условия перепланирования
Автоматически
время выполнения превысило replan_query_execution_time
узел отработал и ошибка прогноза кардинальности оказалась больше
replan_overrun_limit
рабочий процесс использует более replan_memory_limit памяти
и ошибка прогноза кардинальности превысила replan_overrun_limit
Вручную
функция replan_signal
Механизм перепланирования запросов в реальном времени является
частью Postgres Pro, поэтому установки дополнительных расширений
не требуется.
На данный момент у функциональности перепланирования имеются
некоторые ограничения: поддерживаются только операторы SELECT
(за исключением SELECT FOR UPDATE и SELECT FOR SHARE)
и не поддерживаются курсоры и изменчивые (volatile) функции.
В 17-й версии Postgres Pro Enterprise функциональность
перепланирования переименована в адаптивное выполнение запросов
(AQE, Adaptive Query Execution).
8
Особенности
Является частью ядра СУБД
не нужно устанавливать расширения
Ограничения
поддерживает только SELECT
не поддерживает курсоры и изменчивые функции
9
Итоги
Если запрос выполняется неэффективно, сервер может
прервать его и повторить планирование
При перепланировании используется накопленная
информация о кардинальности узлов плана
Перепланирование позволяет автоматически ускорить
проблемные запросы
10
Практика
1. Создайте таблицу с одним столбцом типа char(2000),
с отключенной автоочисткой. Заполните ее данными.
2. Получите план выполнения запроса, выполняющего декартово
произведение таблицы самой с собой. Убедитесь в наличии
ошибки оценки кардинальности.
3. Включите перепланирование, ограничив количество попыток
одной. Получите новый план.
4. Снимите ограничение, установленное на количество попыток
перепланирования. Сравните три получившихся плана.
3. Воспользуйтесь параметром конфигурации replan_max_attempts.
