X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 282A3329CDB for ; Wed, 15 Sep 2004 03:07:27 +0100 (BST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 16741-08 for ; Wed, 15 Sep 2004 02:07:14 +0000 (GMT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id 34A54329C65 for ; Wed, 15 Sep 2004 03:07:17 +0100 (BST) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id E459434F0C; Tue, 14 Sep 2004 19:07:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id E2D9F34DEF; Tue, 14 Sep 2004 19:07:17 -0700 (PDT) Date: Tue, 14 Sep 2004 19:07:17 -0700 (PDT) From: Stephan Szabo To: Robert Davis Cc: pgsql-sql@postgresql.org Subject: Re: explain analyze results are different for each iteration In-Reply-To: <41479917.7010305@faithwestinc.com> Message-ID: <20040914190607.Y35716@megazone.bigpanda.com> References: <41479917.7010305@faithwestinc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200409/102 X-Sequence-Number: 18948 On Tue, 14 Sep 2004, Robert Davis wrote: > I'm trying to benchmark some complex sql queries. One query, in > particular, is causing problems -- its cost values can vary from 228 > to 907, its Total Runtimes from 60 ms to 5176 ms. The query plans > show that the optimizer is choosing different plans for different > iterations of the same query. Does anyone have any idea what's > going on here or maybe how I can force Postgres to prefer the faster > plan? > > The query plans are very long (11 tables joined) but I can include > them if it might help. Thanks for any advice, 11 tables. You might want to see if raising geqo_threshold stabilizes the plans since IIRC that's the threshold for using the genetic optimizer.