From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | mljv(at)planwerk6(dot)de |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Prepared Statements |
Date: | 2008-01-09 20:16:18 |
Message-ID: | Pine.BSO.4.64.0801091507500.27353@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 9 Jan 2008, mljv(at)planwerk6(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Nikolay Samokhvalov | 2008-01-09 20:47:54 | Re: XML path function |
Previous Message | Ivan Sergio Borgonovo | 2008-01-09 20:09:36 | Re: count(*) and bad design was: Experiences with extensibility |