Planning with Actual Bind Values

PostgreSQL does not have a shared query plan cache, but it has an optional query plan cache for prepared statements. That means that the developer has the choice to use a prepared statement with or without cached query plan. But note that the cache is dropped when the prepared statement is closed.

The following samples show how to use this functionality in various languages.


The native C API provides the function PQexecParams, which allows to use bind parameters during prepare (as opposed to PQprepare).


The PostgreSQL JDBC driver controls server-side prepare via the non-standard method setPrepareThreshold on PGStatement and PGConnection.

Note that the default setting is five, which means that the first four executions will actually use the bind parameters during prepare, the later ones not. That counter starts fresh for each PreparedStatement instance.


There are many frameworks that use a PreparedStatement cache—configured via prepared-statement-cache-size in the data source setup. That means you can hit limit at any time.


Ruby’s PGconn.exec accepts bind parameters as optional argument. The values will be used during planning if provided. Jeff Davis has an example.

About the Author

Photo of Markus Winand
Markus Winand tunes developers for high SQL performance. He also published the book SQL Performance Explained and offers in-house training as well as remote coaching at