Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id A309F1337B98 for ; Fri, 21 Jan 2011 14:13:03 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 17101-08 for ; Fri, 21 Jan 2011 18:12:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from lpo-relay-04.vmsinfo.com (lpo-relay-04.vmsinfo.com [216.169.137.115]) by mail.postgresql.org (Postfix) with ESMTP id 2D4041337990 for ; Fri, 21 Jan 2011 14:12:56 -0400 (AST) X-IronPort-AV: E=Sophos;i="4.60,359,1291611600"; d="scan'208";a="28162711" Received: from unknown (HELO lpo-mailbox-01.vmsinfo.com) ([216.169.137.251]) by lpo-relay-04.vmsinfo.com with ESMTP; 21 Jan 2011 13:12:55 -0500 Received: from [10.101.43.35] (unknown [216.169.135.235]) by lpo-mailbox-01.vmsinfo.com (Postfix) with ESMTP id 7F3347D00B; Fri, 21 Jan 2011 13:12:55 -0500 (EST) Message-ID: <4D39CCA7.1040507@vmsinfo.com> Date: Fri, 21 Jan 2011 13:12:55 -0500 From: Mladen Gogala User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Robert Haas CC: Achilleas Mantzios , "pgsql-performance@postgresql.org" Subject: Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2 References: <955263366.48014741295283147090.JavaMail.root@ucimail4.uci.cu> <201101191110.05268.achill@matrix.gatewaynet.com> <21792.1295458016@sss.pgh.pa.us> <201101200905.26400.achill@matrix.gatewaynet.com> <4D39C58D.4060709@vmsinfo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201101/198 X-Sequence-Number: 41985 On 1/21/2011 12:51 PM, Robert Haas wrote: > I am starting to suspect that there is a bug in the join selectivity > logic in 9.0. We've had a few complaints where the join was projected > to return more rows than the product of the inner side and outer side > of the join, which is clearly nonsense. I read the function and I > don't see anything weird... and it clearly can't be too bad or we > would have had more complaints... but... Well the way to test it would be to take the function from 8.3, input the same arguments and see if there is any difference with the results. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions