Расширение sr_plan позволяет пользователям сохранять отдельные планы параметризованных запросов для использования в будущем вне зависимости от изменения параметров планировщика.

Модуль sr_plan действует подобно системе Oracle Outline. Используя его, вы можете жёстко зафиксировать план выполнения. Это бывает необходимо, если вы уверены, что планировщик не сможет выработать лучший план, или вы хотите использовать собственный. Обычно системные администраторы работают с запросами интерактивно и сохраняют лучшие планы для дальнейшего использования в случаях, когда время обработки запроса должно быть предсказуемым. Тогда приложение, работающее с этими запросами, будет использовать сохранённые планы.

Модуль sr_plan включён в состав Postgres Pro Enterprise как стандартное расширение. Чтобы задействовать sr_plan, выполните следующие действия:

Рассмотрим типичный случай, когда есть запрос с низкой производительностью и выбран неудачный план (например, из-за недооценки избирательности используется соединение вложенным циклом вместо хеш-соединения) и есть представление, как исправить этот план (например, SET enable_nestloop = 'off'). Модуль sr_plan позволяет заморозить планы для использования в будущем независимо от возможных изменений параметров планировщика. Сначала необходимо зарегистрировать запрос для работы под управлением sr_plan:

SELECT sr_register_query(query_string, parameter_type, ...);

Здесь query_string — ваш запрос с параметрами $n (аналогично PREPARE statement_name AS). Можно описать каждый тип параметра, используя необязательный аргумент функции parameter_type, или отказаться от явного определения типов параметров. В последнем случае Postgres Pro пытается определить тип каждого параметра из контекста. Эта функция возвращает уникальную пару queryid и const_hash. Обязательно сохраните уникальные queryid и const_hash до конца заморозки плана. Теперь sr_plan будет отслеживать выполнение запросов, соответствующих сохранённому шаблону параметризованного запроса. Для получения приемлемого плана запросов можно использовать любые методы. Затем выполните:

SELECT sr_plan_freeze(queryid, const_hash);

Здесь следует использовать значения queryid и const_hash, возвращаемые функцией sr_register_query. Теперь sr_plan хранит последний использованный план запроса в хранилище файлов, общей памяти и локальном кеше.

Ниже показано, как использовать sr_plan.

Заморозьте план полностью параметризованного запроса, используя параметр конфигурации sr_plan.auto_tracking:

SET sr_plan.auto_tracking = on;

EXPLAIN SELECT count(*) FROM a WHERE x = 1 OR (x > 11 AND x < 22) OR x = 22;

 Custom Scan (SRScan)  (cost=1.60..0.00 rows=1 width=8)
   Plan is: tracked
   Query ID: 5393873830515778388
   Const hash: 0
   ->  Aggregate  (cost=1.60..1.61 rows=1 width=8)
         ->  Seq Scan on a  (cost=0.00..1.60 rows=2 width=0)
               Filter: ((x = $1) OR ((x > $2) AND (x < $3)) OR (x = $4))

-- Укажите возвращённый 'Tracked plan ID':
SELECT sr_plan_freeze(5393873830515778388, 0);

RESET sr_plan.auto_tracking;

Используйте явное приведение, чтобы sr_plan точно находил замороженный план для вашего запроса. Например, следующие операторы sr_plan воспринимает как разные:

SELECT * FROM a WHERE x = 1::integer

SELECT * FROM a WHERE x = 1::bigint

Если в очереди обработчиков планировщика sr_plan не стоит последним, стандартный планировщик, вызываемый последним обработчиком в очереди, оптимизирует нагрузку (иногда значительно). Таким образом, если план уже заморожен, sr_plan удалит такой только что созданный план. Чтобы избежать ненужных издержек, sr_plan должен быть указан последним в списке библиотек shared_preload_libraries.