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 61EBC9DC85B for ; Tue, 24 Jan 2006 19:30:17 -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 65866-10 for ; Tue, 24 Jan 2006 19:30:19 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from exchange.g2switchworks.com (mail.g2switchworks.com [63.87.162.25]) by postgresql.org (Postfix) with ESMTP id 4B22B9DC832 for ; Tue, 24 Jan 2006 19:30:15 -0400 (AST) Received: from 10.10.1.37 ([10.10.1.37]) by exchange.g2switchworks.com ([10.10.1.2]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jan 2006 23:30:18 +0000 Received: from state.g2switchworks.com by mail.g2switchworks.com; 24 Jan 2006 17:30:18 -0600 Subject: Re: Inconsistant query plan From: Scott Marlowe To: Daniel Gish Cc: pgsql-performance@postgresql.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1138145417.25819.39.camel@state.g2switchworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 24 Jan 2006 17:30:18 -0600 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.131 required=5 tests=[AWL=0.130, UNPARSEABLE_RELAY=0.001] X-Spam-Score: 0.131 X-Spam-Level: X-Archive-Number: 200601/425 X-Sequence-Number: 16903 On Tue, 2006-01-24 at 17:15, Daniel Gish wrote: > Hi, > 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 ... > > In the efficient plan, t2 is joined to t3 & t4 before being joined to t1. > The inefficient plan joins t1 to t2 before joining to the other tables. > > We've experimented with different settings, such as shared_buffers & > max_fsm_pages, to no avail. Anybody have a suggestion for getting the > efficient plan to execute consistantly? If you'd like to see the actual > query & query plans let me know. Have you adjusted the stats target for that column? See \h alter table in psql for the syntax for that. Then run analyze again.