This behavior is in some way needed, as PreparedStatement is, commonly, used
once, just to pass parameters without escaping.
Regards,
Radek
-Original Message-
From: Rob Gansevles
Sent: 27 czerwca 2011 08:50
To: pgsql-general
Subject: Re: [GENERAL] Reusing cached prepared statement slow
Dean Rasheed wrote:
>> I can confirm, when I call ps.setPrepareThreshold(1) the query is
slow
>> immediately, so the plan must be different with the server prepared
>> statements.
>
> You can confirm that from psql by doing
>
> EXPLAIN ANALYSE SELECT ... ;
>
> and then
>
> PREPARE ps( ... ) AS SELE
On 27 June 2011 07:50, Rob Gansevles wrote:
> I can confirm, when I call ps.setPrepareThreshold(1) the query is slow
> immediately, so the plan must be different with the server prepared
> statements.
>
You can confirm that from psql by doing
EXPLAIN ANALYSE SELECT ... ;
and then
PREPARE ps( .
I can confirm, when I call ps.setPrepareThreshold(1) the query is slow
immediately, so the plan must be different with the server prepared
statements.
Thanks,
Rob
On Sun, Jun 26, 2011 at 5:11 PM, Tom Lane wrote:
> David Johnston writes:
>> This is likely the case where the first few "prepared
David Johnston writes:
> This is likely the case where the first few "prepared statements" are
> not truly prepared. Once you hit five the cache kicks in and computes
> a generic query plan to cache.
Not so much that as that JDBC decides that it should tell the backend to
start using a prepared
This is likely the case where the first few "prepared statements" are not truly
prepared. Once you hit five the cache kicks in and computes a generic query
plan to cache. Since this plan is generic, where the first five were specific,
it exhibits worse performance than queries where the where
