Thanks a lot for this info, I was indeed exceeding the genetic
optimizer's threshold. Now that it is turned off, I get
a very stable response time of 435ms (more or less 5ms) for
the same query. It is about three times slower than the best
I got with the genetic optimizer on, but the overall average
is much lower.
I'll also try to play with the geqo parameters and see if things
improve.
Thanks again,
J-P
-----Original Message-----
From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Tom Lane
Sent: January 11, 2006 6:03 PM
To: Jean-Philippe Côté
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Extremely irregular query performance
=?iso-8859-1?Q?Jean-Philippe_C=F4t=E9?= <jean-philippe.cote@crt.umontreal.ca> writes:
> I'm running version 8.1 on a dedicated Sun v20 server (2 AMD x64's)
> with 4Gb of RAM. I have recently noticed that the performance of
> some more complex queries is extremely variable and irregular.
> For example, I currently have a query that returns a small number
> of rows (5) by joining a dozen of tables.
A dozen tables? You're exceeding the geqo_threshold and getting a plan
that has some randomness in it. You could either increase
geqo_threshold if you can stand the extra planning time, or try
increasing geqo_effort to get it to search a little harder and hopefully
find a passable plan more often. See
http://www.postgresql.org/docs/8.1/static/geqo.html
http://www.postgresql.org/docs/8.1/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO
I'm kinda surprised that you don't get better results with the default
settings. We could tinker some more with the defaults, if you can
provide evidence about better values ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match