Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id E7A2A9F97D1 for ; Wed, 10 Oct 2007 15:55:04 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 77472-03 for ; Wed, 10 Oct 2007 15:54:49 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from outmail136034.authsmtp.co.uk (outmail136034.authsmtp.co.uk [62.13.136.34]) by postgresql.org (Postfix) with ESMTP id 70CF59F9462 for ; Wed, 10 Oct 2007 15:54:50 -0300 (ADT) Received: from outmail128184.authsmtp.net (outmail128184.authsmtp.net [62.13.128.184]) by punt3.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id l9AIsjBS083542; Wed, 10 Oct 2007 19:54:45 +0100 (BST) Received: from [192.168.0.3] (85-211-149-22.dyn.gotadsl.co.uk [85.211.149.22]) (authenticated bits=0) by mail.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id l9AIsisB010057; Wed, 10 Oct 2007 19:54:44 +0100 (BST) Subject: Re: hashjoin chosen over 1000x faster plan From: Simon Riggs To: Kevin Grittner Cc: Tom Lane , pgsql-performance@postgresql.org In-Reply-To: <470CD3E3.EE98.0025.0@wicourts.gov> References: <470B99BE.EE98.0025.0@wicourts.gov> <1191997904.4233.125.camel@ebony.site> <470C9813.EE98.0025.0@wicourts.gov> <1192035955.4233.306.camel@ebony.site> <1192035955.4233.306.camel@ebony.site> <20980.1192039650@sss.pgh.pa.us> <470CD3E3.EE98.0025.0@wicourts.gov> Content-Type: text/plain Date: Wed, 10 Oct 2007 19:54:52 +0100 Message-Id: <1192042492.4233.334.camel@ebony.site> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 7bit X-Server-Quench: 4443c28c-7762-11dc-b86a-001185d377ca X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksadRtFaQVbYlpF HGQLW1NEUVR7XGd/ bw8fZQBDYEtPQQRu WVZLQE1QERpoT0AI d2ddC1oAdwRGeHt3 K0RgW3AVWEB+dhV/ Sh1JEmoAZ3phaTRM TRJQcVJJcANLfxdA PlN4UyBcLwdSbGoL JyIJERcLGAAXKC1O QgMKLFRaSkYMBTM6 DxccEC9nRBVdHzV7 IRU9NlMGVF4VO0Na X-Authentic-SMTP: 61633235383639.squirrel.dmpriest.net.uk:752/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200710/103 X-Sequence-Number: 27125 On Wed, 2007-10-10 at 13:30 -0500, Kevin Grittner wrote: > >>> On Wed, Oct 10, 2007 at 1:07 PM, in message <20980.1192039650@sss.pgh.pa.us>, > Tom Lane wrote: > > Simon Riggs writes: > >> Basically the planner doesn't ever optimise for the possibility of the > >> never-executed case because even a single row returned would destroy > >> that assumption. > > > > It's worse than that: the outer subplan *does* return some rows. > > I suppose that all of them had NULLs in the join keys, which means > > that (since 8.1 or so) nodeMergejoin discards them as unmatchable. > > Had even one been non-NULL the expensive subplan would have been run. > > Well, this query is run tens of thousands of times per day by our web > application; less than one percent of those runs would require the > subplan. (In my initial post I showed counts to demonstrate that 1% > of the rows had a non-NULL value and, while I wouldn't expect the > planner to know this, these tend to be clustered on a lower > percentage of cases.) If the philosophy of the planner is to go for > the lowest average cost (versus lowest worst case cost) shouldn't it > use the statistics for to look at the percentage of NULLs? But the planner doesn't work on probability. It works on a best-guess selectivity, as known at planning time. That's why dynamic planning was invented, which we don't do yet. Don't hold your breath either. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com