Csaba Nagy wrote:
On Tue, 2006-08-08 at 12:36, Constantin Teodorescu wrote:
We have tried PGStatement#setPrepareThreshold with 1 as the threshold
but it's not a good solution.
Actually is worst. Considering that you have 5 different query plans,
you are selecting approx. random one of them, no
On Mon, Aug 07, 2006 at 10:47:39PM +0200, Lukas Smith wrote:
> Constantin Teodorescu wrote:
>
> >EXPLAIN VARIANTS SELECT .. (and so on) that will display the
> >different query plans analyzed by the planner and their "estimated time
> >values" , not just the "best guess" .
> >
> >assuming th
Csaba Nagy wrote:
Constantin,
What binding are you using ? We here use Java+JDBC, and we were able to
get stable query plans by forcing server side prepared statements (using
PGStatement#setPrepareThreshold with 1 as the threshold), where the
query is prepared without knowing the parameter value
On Tue, 2006-08-08 at 12:36, Constantin Teodorescu wrote:
> We have tried PGStatement#setPrepareThreshold with 1 as the threshold
> but it's not a good solution.
> Actually is worst. Considering that you have 5 different query plans,
> you are selecting approx. random one of them, not taking into
Constantin,
What binding are you using ? We here use Java+JDBC, and we were able to
get stable query plans by forcing server side prepared statements (using
PGStatement#setPrepareThreshold with 1 as the threshold), where the
query is prepared without knowing the parameter values. This can
backfire
Constantin Teodorescu wrote:
EXPLAIN VARIANTS SELECT .. (and so on) that will display the
different query plans analyzed by the planner and their "estimated time
values" , not just the "best guess" .
assuming that the EXPLAIN VARIANTS will show 3 or 4 different query
plans, the database
