Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 0DB669FA456 for ; Fri, 31 Aug 2007 21:09:28 -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 95514-03 for ; Fri, 31 Aug 2007 21:09:17 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mir3-fs.mir3.com (mail.mir3.com [65.208.188.100]) by postgresql.org (Postfix) with ESMTP id AEE629F960E for ; Fri, 31 Aug 2007 21:09:21 -0300 (ADT) Received: MIR3-FS.mir3.com 172.16.1.11 from 172.16.2.68 172.16.2.68 via HTTP with MS-WebStorage 6.0.6249 Received: from archimedes by MIR3-FS.mir3.com; 31 Aug 2007 17:09:18 -0700 Subject: Re: Fwd: 8.2 Query 10 times slower than 8.1 (view-heavy) From: Mark Lewis To: Tom Lane Cc: Evan Carroll , pgsql-performance@postgresql.org In-Reply-To: <4484.1188603565@sss.pgh.pa.us> References: <428b865e0708280822u522391ecr5366bb5a6647f1aa@mail.gmail.com> <428b865e0708280901x3776581qc424bb2c52531475@mail.gmail.com> <428b865e0708280923k57b8cbe4l3dd01fca75975c3f@mail.gmail.com> <428b865e0708280924ye13ead1j5c198778cdea9c6@mail.gmail.com> <1188319891.22730.63.camel@archimedes> <1368.1188326880@sss.pgh.pa.us> <4484.1188603565@sss.pgh.pa.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: MIR3, Inc. Date: Fri, 31 Aug 2007 17:09:17 -0700 Message-Id: <1188605357.5367.14.camel@archimedes> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200708/415 X-Sequence-Number: 26545 On Fri, 2007-08-31 at 19:39 -0400, Tom Lane wrote: > I wrote: > > Mark Lewis writes: > >> We've been holding back from upgrading to 8.2 because this one is a > >> show-stopper for us. > > > Well, you could always make your own version with this patch reverted: > > http://archives.postgresql.org/pgsql-committers/2006-11/msg00066.php > > I might end up doing that in the 8.2 branch if a better solution > > seems too large to back-patch. > > I thought of a suitably small hack that should cover at least the main > problem without going so far as to revert that patch entirely. What we > can do is have the IS NULL estimator recognize when the clause is being > applied at an outer join, and not believe the table statistics in that > case. I've applied the attached patch for this --- are you interested > in trying it out on your queries before 8.2.5 comes out? Wish I could, but I'm afraid that I'm not going to be in a position to try out the patch on the application that exhibits the problem for at least the next few weeks. -- Mark