From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Dean Rasheed *EXTERN*" <dean(dot)a(dot)rasheed(at)gmail(dot)com>, "Rob Gansevles" <rgansevles(at)gmail(dot)com> |
Cc: | "pgsql-general" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Reusing cached prepared statement slow after 5 executions |
Date: | 2011-06-27 11:54:32 |
Message-ID: | D960CB61B694CF459DCFB4B0128514C20694A8A8@exadv11.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 SELECT ... ;
> EXPLAIN ANALYSE EXECUTE ps ( ... ) ;
>
> using your query and the parameters in question.
>
> It is entirely possible that the plan chosen for the prepared
> statement will be worse than the one used when the parameters are
> known at planning time. The prepared statement doesn't know what
> parameters are going to be used, so it can't always come up with the
> best plan. See the notes in the PREPARE manual page:
> http://www.postgresql.org/docs/9.0/static/sql-prepare.html
Could the parameter cursor_tuple_fraction play a role here too?
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Sim Zacks | 2011-06-27 12:36:48 | discard on constraint violation |
Previous Message | Leif Biberg Kristensen | 2011-06-27 10:11:21 | Re: An amusing MySQL weakness--not! |