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 CA1029DCAB8 for ; Tue, 24 Jan 2006 19:59:06 -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 70097-08 for ; Tue, 24 Jan 2006 19:59:09 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from tigger.fuhr.org (tigger.fuhr.org [63.214.45.158]) by postgresql.org (Postfix) with ESMTP id 321BC9DCAAD for ; Tue, 24 Jan 2006 19:59:04 -0400 (AST) Received: from winnie.fuhr.org (winnie.fuhr.org [10.1.0.1]) by tigger.fuhr.org (8.13.3/8.13.3) with ESMTP id k0ONww2T027499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2006 16:59:00 -0700 (MST) (envelope-from mfuhr@winnie.fuhr.org) Received: from winnie.fuhr.org (localhost [127.0.0.1]) by winnie.fuhr.org (8.13.4/8.13.4) with ESMTP id k0ONwvWJ092458; Tue, 24 Jan 2006 16:58:57 -0700 (MST) (envelope-from mfuhr@winnie.fuhr.org) Received: (from mfuhr@localhost) by winnie.fuhr.org (8.13.4/8.13.4/Submit) id k0ONwvlr092457; Tue, 24 Jan 2006 16:58:57 -0700 (MST) (envelope-from mfuhr) Date: Tue, 24 Jan 2006 16:58:57 -0700 From: Michael Fuhr To: Daniel Gish Cc: pgsql-performance@postgresql.org Subject: Re: Inconsistant query plan Message-ID: <20060124235857.GA92385@winnie.fuhr.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.108 required=5 tests=[AWL=0.108] X-Spam-Score: 0.108 X-Spam-Level: X-Archive-Number: 200601/426 X-Sequence-Number: 16904 On Tue, Jan 24, 2006 at 04:15:57PM -0700, Daniel Gish wrote: > We are running Postgresql 8.1, and getting dramatically inconsistant results > after running VACUUM ANALYZE. Sometimes after analyzing the database, the > query planner chooses a very efficient plan (15 rows, 4.744 ms), and > sometimes a terrible one (24 rows, 3536.995 ms). Here's the abbreviated > query: > > SELECT * FROM t1 INNER JOIN (t2 INNER JOIN (t3 INNER JOIN t4 ON t3.gid = > t4.gid) ON t3.gid = t2.gid) ON t2.eid = t1.eid WHERE ... How abbreviated is that example? Are you actually joining more tables than that? In another recent thread varying plans were attributed to exceeding geqo_threshold: http://archives.postgresql.org/pgsql-performance/2006-01/msg00132.php Does your situation look similar? -- Michael Fuhr