Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 8B2059FA5F9 for ; Sun, 22 Apr 2007 19:39:11 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 40684-10 for ; Sun, 22 Apr 2007 19:38:57 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from bay0-omc3-s21.bay0.hotmail.com (bay0-omc3-s21.bay0.hotmail.com [65.54.246.221]) by postgresql.org (Postfix) with ESMTP id 882A29FA5EE for ; Sun, 22 Apr 2007 19:39:07 -0300 (ADT) Received: from hotmail.com ([65.54.161.34]) by bay0-omc3-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 22 Apr 2007 15:39:06 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 22 Apr 2007 15:39:06 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sun, 22 Apr 2007 22:39:04 GMT X-Originating-IP: [86.81.58.36] X-Originating-Email: [henk53602@hotmail.com] X-Sender: henk53602@hotmail.com In-Reply-To: <10143.1177274553@sss.pgh.pa.us> From: "henk de wit" To: tgl@sss.pgh.pa.us Cc: pgsql-performance@postgresql.org Subject: Re: Redundant sub query triggers slow nested loop left join Date: Mon, 23 Apr 2007 00:39:04 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Apr 2007 22:39:06.0216 (UTC) FILETIME=[08DF5680:01C7852F] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.647 tagged_above=0 required=5 tests=AWL=-0.262, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_HEADER=0 X-Spam-Level: * X-Archive-Number: 200704/373 X-Sequence-Number: 24250 >You might be able to improve matters by increasing the statistics target >for this table. I have tried to increase the statistics for the status column to the maximum of 1000. After that I performed an analyze, vacuum analyze and vacuum full analyze on the table. Unfortunately this didn't seem to make any difference. >I have a bad feeling though that the problem may be >lack of cross-column statistics I assume this isn't a thing that can be tweaked/increased in PG 8.2? >--- the thing is evidently assuming >that only about 1 in 200 rows have status = '0', which might be accurate >as a global average but not for this particular merchant. What exactly >is the relationship between status and merchant_id, anyway? The meaning is that a "banners_link" belongs to a merchant with the id merchant_id. A "banners_link" can be disabled (status 1) or enabled (status 0). Globally about 1/3 of the banners_links have status 0 and 2/3 have status 1. The 1 in 200 estimate is indeed way off. For the merchant in question the numbers are a bit different though, but not that much. Out of 424 rows total, 359 have status 0 and 65 have status 1. _________________________________________________________________ FREE pop-up blocking with the new Windows Live Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/