X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 27FAA9DC8A2 for ; Thu, 12 Jan 2006 05:49:00 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 86671-03 for ; Thu, 12 Jan 2006 05:49:01 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by postgresql.org (Postfix) with ESMTP id EF8099DC888 for ; Thu, 12 Jan 2006 05:48:57 -0400 (AST) Received: from [192.168.0.3] (unknown [84.12.152.182]) by smtp.nildram.co.uk (Postfix) with ESMTP id D56162531ED; Thu, 12 Jan 2006 09:48:39 +0000 (GMT) Subject: Re: Extremely irregular query performance From: Simon Riggs To: Tom Lane Cc: Jean-Philippe =?ISO-8859-1?Q?C=F4t=E9?= , pgsql-performance@postgresql.org In-Reply-To: <480.1137036235@sss.pgh.pa.us> References: <20060111234149.05DEA384099@crt0.crt.umontreal.ca> <480.1137036235@sss.pgh.pa.us> Content-Type: text/plain Date: Thu, 12 Jan 2006 09:48:41 +0000 Message-Id: <1137059321.3180.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.06 required=5 tests=[AWL=0.060] X-Spam-Score: 0.06 X-Spam-Level: X-Archive-Number: 200601/150 X-Sequence-Number: 16628 On Wed, 2006-01-11 at 22:23 -0500, Tom Lane wrote: > =?iso-8859-1?Q?Jean-Philippe_C=F4t=E9?= writes: > > 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. > > Hmm. It would be interesting to use EXPLAIN ANALYZE to confirm that the > plan found this way is the same as the best plan found by GEQO, and > the extra couple hundred msec is the price you pay for the exhaustive > plan search. If GEQO is managing to find a plan better than the regular > planner then we need to look into why ... It seems worth noting in the EXPLAIN whether GEQO has been used to find the plan, possibly along with other factors influencing the plan such as enable_* settings. Best Regards, Simon Riggs