Re: Prepared Statements - Mailing list pgsql-general

From Kris Jurka
Subject Re: Prepared Statements
Date
Msg-id Pine.BSO.4.64.0801091507500.27353@leary.csoft.net
Whole thread Raw
In response to Prepared Statements  (mljv@planwerk6.de)
Responses Re: Prepared Statements  (mljv@planwerk6.de)
List pgsql-general

On Wed, 9 Jan 2008, mljv@planwerk6.de wrote:

> - I know there is a PREPARE Statement in Postgresql and read the docs.
> - in PostgresqlJDBC i have a prepareThreshold parameter which i left to
> default of 5.
> - in DBCP i have a property "poolPreparedStatements", set to true. Does ist
> just configure prepareThreshold of JDBC or does it maintain a statementPool
> of it's own?

The postgresql JDBC driver does not have a statement pool of its own, so
the two options prepareThreshold and poolPreparedStatements are
complementary.  By itself the JDBC driver will switch to a long term
prepared plan once you've used the exact same PreparedStatement object
prepareThreshold number of times.  Since it doesn't pool things behind the
scenes, you've got to retain a reference to the same PreparedStatement
object which is difficult or impossible in many applications.  This is
where the DBCP statement pool comes in.  It proxies PreparedStatement
wrappers to one underlying PG PreparedStatement object so that you can hit
prepareThreshold.

> In my Log files of postgresql each query is called like this:
>
>    EXECUTE <unnamed> [PREPARE: select ...]
>
> I have not found anything about preparing "unnamed" statements. What
> does it mean?
>

Unnamed statements are what the driver uses before it hits the
prepareThreshold limit.  Once it has determined the statement will be
reused many times it changes to a named statement that has a longer
lifespan.

Kris Jurka

pgsql-general by date:

Previous
From: Ivan Sergio Borgonovo
Date:
Subject: Re: count(*) and bad design was: Experiences with extensibility
Next
From: "Nikolay Samokhvalov"
Date:
Subject: Re: XML path function