PREPARE
PREPARE — подготовить оператор к выполнению
Синтаксис
PREPAREимя
[ (тип_данных
[, ...] ) ] ASоператор
Описание
PREPARE
создаёт подготовленный оператор. Подготовленный оператор представляет собой объект на стороне сервера, позволяющий оптимизировать производительность приложений. Когда выполняется PREPARE
, указанный оператор разбирается, анализируется и переписывается. При последующем выполнении команды EXECUTE
подготовленный оператор планируется и исполняется. Такое разделение труда исключает повторный разбор запроса, при этом позволяет выбрать наилучший план выполнения в зависимости от определённых значений параметров.
Подготовленные операторы могут принимать параметры — значения, которые подставляются в оператор, когда он собственно выполняется. При создании подготовленного оператора к этим параметрам можно обращаться по порядковому номеру, используя запись $1
, $2
и т. д. Дополнительно можно указать список соответствующих типов данных параметров. Если тип данных параметра не указан или объявлен как unknown
(неизвестный), тип выводится из контекста при первом обращении к этому параметру (если это возможно). При выполнении оператора фактические значения параметров передаются команде EXECUTE
. За подробностями обратитесь к EXECUTE.
Подготовленные операторы существуют только в рамках текущего сеанса работы с БД. Когда сеанс завершается, система забывает подготовленный оператор, так что его надо будет создать снова, чтобы использовать дальше. Это также означает, что один подготовленный оператор не может использоваться одновременно несколькими клиентами базы данных; но каждый клиент может создать собственный подготовленный оператор и использовать его. Освободить подготовленный оператор можно вручную, выполнив команду DEALLOCATE.
Подготовленные операторы потенциально дают наибольший выигрыш в производительности, когда в одном сеансе выполняется большое число однотипных операторов. Отличие в производительности особенно значительно, если операторы достаточно сложны для планирования или перезаписи, например, когда в запросе объединяется множество таблиц или необходимо применить несколько правил. Если оператор относительно прост в этом плане, но сложен для выполнения, выигрыш от использования подготовленных операторов будет менее заметным.
Параметры
имя
Произвольное имя, назначаемое данному подготовленному оператору. Оно должно быть уникальным в рамках одного сеанса; это имя затем используется для выполнения или освобождения ранее подготовленного оператора.
тип_данных
Тип данных параметра подготовленного оператора. Если тип данных конкретного параметра не задан или задан как
unknown
, он будет выводиться из контекста при первом обращении к этому параметру. Для обращения к параметрам в самом подготовленном операторе используется запись$1
,$2
и т. д.оператор
Любой оператор
SELECT
,INSERT
,UPDATE
,DELETE
илиVALUES
.
Замечания
Подготовленные операторы могут использовать общие планы, а не перестраивать план для каждого набора переданных значений EXECUTE
. Для подготовленных операторов без параметров это происходит сразу; иначе общий план выбирается после пяти и более выполнений, при которых получаются планы с ожидаемой средней стоимостью (включая издержки планирования), превышающей оценку стоимости общего плана. Когда общий план выбран, он будет использоваться до конца жизни подготовленного оператора. При использовании значений EXECUTE
, которые редко встречаются в столбцах со множеством дублирующихся значений, могут быть построены специализированные планы настолько выгоднее общего плана, что даже с издержками планирования общий план может не использоваться никогда.
Для общего плана предполагается, что значения, передаваемые в EXECUTE
, являются уникальными значениями в столбце и что эти значения распределены равномерно. Например, если в статистике записаны три различных значения столбца, с общим планом предполагается, что проверке на равенство для столбца будут соответствовать 33% обработанных строк. Статистика по столбцам также позволяет общим планам точно вычислять избирательность для уникальных столбцов. Сравнения по столбцам с неоднородным распределением и указания несуществующих значений влияют на среднюю стоимость плана и следовательно, на то, будет ли выбран общий план и когда.
По умолчанию в памяти сохраняются общие планы только для 64 последних подготовленных операторов; предыдущие операторы потребуется разбирать и анализировать снова, если они будут вызываться. Это ограничение устанавливается параметром конфигурации plan_cache_lru_size, что позволяет управлять объёмом памяти, занимаемым подготовленными операторами. Если вы хотите, чтобы по мере возможности в памяти сохранялись планы для всех подготовленных операторов, задайте для этого параметра значение 0
.
Чтобы узнать, какой план выполнения выбирает Postgres Pro для подготовленного оператора, воспользуйтесь EXPLAIN (например, напишите EXPLAIN EXECUTE
). Если применяется общий план, он будет содержать символы параметров $
, тогда как в специализированном плане будут подставлены фактические значения параметров. Оценки строк в общем плане отражают избирательность, вычисленную для конкретных параметров.n
Более подробно о планировании запросов и статистике, которую собирает Postgres Pro для этих целей, можно узнать в документации ANALYZE.
Хотя основной смысл подготовленных операторов в том, чтобы избежать многократного разбора и планирования оператора, Postgres Pro будет принудительно заново анализировать и планировать выполнение оператора всякий раз, когда объекты базы данных, задействованные в операторе, подвергаются изменениям определения (DDL) со времени предыдущего использования подготовленного оператора. Кроме того, если от одного использования оператора к другому меняется значение search_path, оператор будет так же разобран заново с новым search_path
. (Последнее поведение появилось в PostgreSQL 9.3.) С этими правилами использование подготовленного оператора по сути почти не отличается от выполнения одного и того же запроса снова и снова, но даёт выигрыш по скорости (если определения объектов не меняются), особенно если оптимальный план от раза к разу не меняется. Однако различия всё же могут проявиться — например, когда оператор обращается к таблице по неполному имени, а затем в схеме, стоящей в пути search_path
раньше, создаётся другая таблица с таким же именем, автоматический пересмотр запроса не происходит, так как никакой объект в определении оператора не изменился. Однако если автоматический пересмотр произойдёт в результате других изменений, при последующем выполнении запроса будет задействована новая таблица.
Получить список всех доступных в сеансе подготовленных операторов можно, обратившись к системному представлению pg_prepared_statements
.
Примеры
Создание подготовленного оператора для команды INSERT
, который затем выполняется:
PREPARE fooplan (int, text, bool, numeric) AS INSERT INTO foo VALUES($1, $2, $3, $4); EXECUTE fooplan(1, 'Hunter Valley', 't', 200.00);
Создание подготовленного оператора для команды SELECT
, который затем выполняется:
PREPARE usrrptplan (int) AS SELECT * FROM users u, logs l WHERE u.usrid=$1 AND u.usrid=l.usrid AND l.date = $2; EXECUTE usrrptplan(1, current_date);
Заметьте, что тип данных второго параметра не указывается, так что он выводится из контекста, в котором используется $2
.
Совместимость
В стандарте SQL есть оператор PREPARE
, но он предназначен только для применения во встраиваемом SQL. Эта версия оператора PREPARE
имеет также несколько другой синтаксис.