Prepared statements
Psycopg uses an automatic system to manage prepared statements. When a query is prepared, its parsing and planning is stored in the server session, so that further executions of the same query on the same connection (even with different parameters) are optimised.
A query is prepared automatically after it is executed more than prepare_threshold
times on a connection. psycopg
will make sure that no more than prepared_max
statements are planned: if further queries are executed, the least recently used ones are deallocated and the associated resources freed.
Statement preparation can be controlled in several ways:
- You can decide to prepare a query immediately by passing
prepare=True
toConnection.execute()
orCursor.execute()
. The query is prepared, if it wasn’t already, and executed as prepared from its first use. - Conversely, passing
prepare=False
toexecute()
will avoid to prepare the query, regardless of the number of times it is executed. The default for the parameter isNone
, meaning that the query is prepared if the conditions described above are met. - You can disable the use of prepared statements on a connection by setting its
prepare_threshold
attribute toNone
.
Changed in version 3.1: You can set prepare_threshold
as a connect()
keyword parameter too.
The PREPARE PostgreSQL documentation contains plenty of details about prepared statements in PostgreSQL.
Note however that Psycopg doesn’t use SQL statements such as
PREPARE
andEXECUTE
, but protocol level commands such as the ones exposed byPQsendPrepare
,PQsendQueryPrepared
.
Using external connection poolers, such as PgBouncer, is not compatible with prepared statements, because the same client connection may change the server session it refers to. If such middleware is used you should disable prepared statements, by setting theConnection.prepare_threshold
attribute toNone
.