Руководство по созданию эффективных запросов

Листинг 12.6 

Примеры вызовов функций
-- № 1
SELECT * FROM select_booking_leg_country('US', '2020-07-01');
-- № 2
SELECT * FROM select_booking_leg_country('US', '2020-08-01');
-- № 3
SELECT * FROM select_booking_leg_country('US', '2020-08-15');
-- № 4
SELECT * FROM select_booking_leg_country('CZ', '2020-08-01');
Наблюдаемое время выполнения будет отличаться в зависимости от того, 
какие параметры передавались функции при первых вызовах. В результате 
время выполнения команды № 3, которое должно занять около 10 секунд, 
может варьироваться от 10 секунд до одной минуты, в зависимости от по-
следовательности вызовов и времени, в течение которого вы делаете паузу 
между ними. Можно открыть несколько соединений с вашим локальным 
PostgreSQL и попробовать разный порядок вызовов.
Почему функция ведет себя так непоследовательно? Вспомните главу 11, 
где говорится, что PostgreSQL 
может
сохранять план выполнения подготов-
ленного оператора. Когда функция вызывается в первый раз в сеансе, каждая 
выполняемая инструкция SQL разбирается, ее план выполнения оптимизи-
руется и 
может
быть закеширован для последующих выполнений.
Мы намеренно не описываем конкретное поведение для каждой последо-
вательности вызовов, потому что здесь нет гарантий. И хотя отсутствие га-
рантий допустимо для обучающей базы данных, оно совершенно неприемле-
мо в промышленном окружении, особенно когда в системе OLTP ограничено 
максимальное время ожидания и транзакции, превышающие установленный 
предел, прерываются.
Чтобы гарантировать, что каждый раз при вызове функции 
план
выполне-
ния
будет
оптимизироваться
для
определенных
значений
, мы создаем функ-
ции, выполняющие динамический SQL.
В лис тинге 12.7 показана функция 
select_booking_leg_country_dynamic
, ко-
торая выполняет точно такой же запрос, что и функция 
select_booking_leg_
country
. Единственное отличие состоит в том, что первая функция создает 
команду 
SELECT
внутри функции, а затем выполняет ее.
Эта функция принимает тот же набор параметров, что и 
select_booking_leg_
country
, и возвращает тот же результат. Но обратите внимание, что время ее 
выполнения для каждого набора параметров неизменно, а это именно то, что 
нужно в промышленных системах.
Почему поведение изменилось? Поскольку SQL создается непосредствен-
но перед выполнением, оптимизатор не использует кешированный план. 
Вместо этого он заново строит план для каждого выполнения. Может пока-

---

Как использовать динамический SQL в системах OLAP 

227
заться, что на это требуется дополнительное время, но на самом деле про-
исходит обратное. Время планирования составляет менее 100 мс; это оку-
пается за счет более подходящего плана выполнения, и в итоге экономится 
значительное время.