Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 98A9B1337B49 for ; Fri, 25 Mar 2011 22:03:25 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 48175-04 for ; Sat, 26 Mar 2011 01:03:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp-1.01.com (smtp-1.01.com [38.102.63.180]) by mail.postgresql.org (Postfix) with ESMTP id 286F5133616B for ; Fri, 25 Mar 2011 22:03:18 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-1.01.com (Postfix) with ESMTP id A1FD8E2662; Fri, 25 Mar 2011 20:03:17 -0500 (CDT) Received: from smtp-1.01.com ([127.0.0.1]) by localhost (smtp-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dcdg828o7sQu; Fri, 25 Mar 2011 20:03:17 -0500 (CDT) Received: by smtp-1.01.com (Postfix, from userid 99) id 8891FE26C7; Fri, 25 Mar 2011 20:03:17 -0500 (CDT) Received: from mail-1.01.com (mail-1.01.com [38.102.63.171]) by smtp-1.01.com (Postfix) with ESMTP id 74F5AE2662; Fri, 25 Mar 2011 20:03:17 -0500 (CDT) Date: Fri, 25 Mar 2011 20:03:17 -0500 (CDT) From: Joshua Berkus To: Tom Lane Cc: Claudio Freire , postgres performance list Message-ID: <634838041.271503.1301101397390.JavaMail.root@mail-1.01.com> In-Reply-To: <3210.1301063084@sss.pgh.pa.us> Subject: Re: Shouldn't we have a way to avoid "risky" plans? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [64.81.245.111] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Mac)/6.0.10_GA_2692) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201103/340 X-Sequence-Number: 43019 > mergejoinscansel doesn't currently try to fix up the histogram bounds > by > consulting indexes. At the time I was afraid of the costs of doing > that, and I still am; but it would be a way to address this issue. Oh? Hmmm. I have a ready-made test case for the benefit case on this. However, I'm not clear on how we would test the costs. But this type of query plan is clearly pathological, and is experienced by users as a performance regression since 8.3. I now have the user doing analyzes of fairly large tables 2/hour to avoid the problem. So I don't think we can leave it alone. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com San Francisco