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 5840E9DC998 for ; Wed, 25 Jan 2006 05:05:46 -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 27277-08 for ; Wed, 25 Jan 2006 05:05:46 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.barettadeit.com (unknown [213.255.109.130]) by postgresql.org (Postfix) with ESMTP id 7A5239DC98D for ; Wed, 25 Jan 2006 05:05:42 -0400 (AST) Received: from [10.0.0.10] (alex.barettalocal.com [10.0.0.10]) by mail.barettadeit.com (Postfix) with ESMTP id 340BF12563; Wed, 25 Jan 2006 10:06:05 +0100 (CET) Message-ID: <43D73F68.3040306@barettadeit.com> Date: Wed, 25 Jan 2006 10:05:44 +0100 From: Alessandro Baretta User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Gish Cc: Michael Fuhr , pgsql-performance@postgresql.org Subject: Re: Inconsistant query plan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.12 required=5 tests=[AWL=0.120] X-Spam-Score: 0.12 X-Spam-Level: X-Archive-Number: 200601/428 X-Sequence-Number: 16906 Daniel Gish wrote: > Hi, > Thanks for your response. The actual query is below; the joins are only 4 > deep. Adjusting the stats target did help, but not dramatically. > > QUERY PLAN > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > --------------------------------------- > Nested Loop (cost=978.19..37161.81 rows=133 width=4) (actual > time=2511.676..2511.676 rows=0 loops=1) > -> Merge Join (cost=978.19..22854.00 rows=4244 width=4) (actual > time=1718.420..2510.128 rows=92 loops=1) > ... > -> Nested Loop (cost=0.00..974.33 rows=113 width=8) (actual time=0.078..2.305 rows=19 loops=1) I have a similar problem recently. An importat diagnostic tool for these issues is the pg_stats view. Let me suggest that you post the relevant lines from pg_stats, so that with some help you will be able to discover what data advises the query planner to overestimate the cardinality of some joins and underestimate others. Alex -- ********************************************************************* http://www.barettadeit.com/ Baretta DE&IT A division of Baretta SRL tel. +39 02 370 111 55 fax. +39 02 370 111 54 Our technology: The Application System/Xcaml (AS/Xcaml) The FreerP Project