зеркало из
https://github.com/iharh/notes.git
synced 2025-11-02 22:56:09 +02:00
67 строки
5.6 KiB
Plaintext
67 строки
5.6 KiB
Plaintext
DEALLOCATE ALL;
|
|
|
|
spring.datasource.hikari.data-source-properties.prepareThreshold=0
|
|
spring.datasource.hikari.max-lifetime=1800000
|
|
spring.datasource.hikari.connection-timeout=30000
|
|
spring.datasource.hikari.minimum-idle=2
|
|
spring.datasource.hikari.maximum-pool-size=10
|
|
|
|
2021
|
|
https://habr.com/ru/companies/postgrespro/articles/574702/
|
|
|
|
**********************************************************************************************************
|
|
Подготовленные запросы (PREPARE statement) в PostgreSQL.
|
|
|
|
Вчера мы с вами поговорили (https://t.me/pg_guru/728) об этапах прохождения запроса и видах протоколов запросов в PostgreSQL. И упомянули о так называемых подготовленных запросах. В сегодняшнем посте более подробно поговорим об этой технологии.
|
|
|
|
Подготовленные запросы относятся к расширенному протоколу запросов и позволяют нам подготовить запрос заранее для выполнения, указав все необходимые параметры. Это может быть полезно, если у вас есть часто выполняющиеся одинаковые по сути запросы, отличающиеся только передаваемыми в них параметрами. С помощью подготовленных запросов мы можем проскочить этапы выполнения запроса, такие как разбор и трансформация, увеличив тем самым производительность.
|
|
|
|
Синтаксис подготовленного запроса будет таким:
|
|
|
|
PREPARE имя_запроса [ ( типы_данных [, ...] ) ] AS текст_запроса параметры_запроса;
|
|
|
|
Имя_запроса - произвольное имя подготовленного запроса. Пригодиться нам для последующего выполнения запроса;
|
|
|
|
Типы_данных - перечисляем типы данных, фигурирующих в запросе поочерёдно. Если не указать тип данных для параметра, то этот параметр будет выведен из контекста запроса, если это возможно;
|
|
|
|
Текст_запроса - собственно, текст самого запроса. Здесь может быть любой SQL-оператор: SELECT, INSERT, UPDATE, DELETE, MERGE или VALUES;
|
|
|
|
Параметры_запроса - перечисляем параметры нашего запроса в виде $1, $2 и т.д. Очередность параметров должна соответствовать очерёдности типов данных.
|
|
|
|
Пример:
|
|
|
|
PREPARE workers (INT, TEXT, DATE) AS
|
|
INSERT INTO workers_info VALUES($1, $2, $3);
|
|
|
|
В ответ получим сообщение:
|
|
|
|
PREPARE
|
|
|
|
Что говорит об успешной подготовке запроса.
|
|
|
|
Теперь нам нужно выполнить подготовленный запрос. Для этого используется команда EXECUTE. Синтаксис будет таким:
|
|
|
|
EXECUTE имя_подготовленного_запроса (значение_первого_параметра, значение_второго_параметра, ...);
|
|
|
|
Продолжая наш пример, выполнение подготовленного запроса может выглядеть так:
|
|
|
|
EXECUTE workers (3, 'Ivan', '1982-01-01');
|
|
|
|
Чтобы удалить подготовленный запрос, используется команда DEALLOCATE. Синтаксис будет таким:
|
|
|
|
DEALLOCATE имя_подготовленного_запроса;
|
|
|
|
В нашем случае будет так:
|
|
|
|
DEALLOCATE workers;
|
|
|
|
Мы так же можем узнать какой план выбирает PostgreSQL для нашего подготовленного запроса:
|
|
|
|
EXPLAIN EXECUTE имя_подготовленного_запроса (значения_параметров);
|
|
|
|
Если PostgreSQL применит общий план запросов, то вместо значений параметров вы увидите символ $n в плане выполнения запросов, если это будет индивидуальный план, то вы увидите значения фактических параметров.
|
|
|
|
Подготовленные запросы существуют только в рамках одной сессии. Если сессия завершилась, то PostgreSQL забудет про такой запрос и в следующий раз его придется подготовить заново.
|
|
|
|
Подготовленные запросы дают максимальный выигрыш в производительности тогда, когда в одном сеансе выполняется много однотипных запросов, особенно если в запросах используются сложные операции объединения таблиц или еще какие-то. Подготовленные запросы позволяют PostgreSQL избежать лишней подготовки и трансформации запроса, что повышает производительность системы.
|