Received: from localhost (maia-1.hub.org [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 9BF3E9FA1ED
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 28 Aug 2007 15:48:14 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 96975-02 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 28 Aug 2007 15:48:08 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 93BD69F9651
	for <pgsql-performance@postgresql.org>;
	Tue, 28 Aug 2007 15:48:06 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id l7SIm1Cb001369;
	Tue, 28 Aug 2007 14:48:01 -0400 (EDT)
To: Mark Lewis <mark.lewis@mir3.com>
cc: Evan Carroll <lists@evancarroll.com>, pgsql-performance@postgresql.org
Subject: Re: Fwd: 8.2 Query 10 times slower than 8.1 (view-heavy) 
In-reply-to: <1188319891.22730.63.camel@archimedes> 
References: <428b865e0708280822u522391ecr5366bb5a6647f1aa@mail.gmail.com>
	<dcc563d10708280832u4b0b9abbh1b5053bd1b2a9149@mail.gmail.com>
	<428b865e0708280901x3776581qc424bb2c52531475@mail.gmail.com>
	<dcc563d10708280907r4b67217eta560c8eab710ab3c@mail.gmail.com>
	<428b865e0708280923k57b8cbe4l3dd01fca75975c3f@mail.gmail.com>
	<428b865e0708280924ye13ead1j5c198778cdea9c6@mail.gmail.com>
	<1188319891.22730.63.camel@archimedes>
Comments: In-reply-to Mark Lewis <mark.lewis@mir3.com>
	message dated "Tue, 28 Aug 2007 09:51:31 -0700"
Date: Tue, 28 Aug 2007 14:48:00 -0400
Message-ID: <1368.1188326880@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200708/363
X-Sequence-Number: 26493

Mark Lewis <mark.lewis@mir3.com> writes:
> Unfortunately there has been a planner regression in 8.2 in some cases
> with these forms of queries.  This was discussed a few weeks (months?)
> ago on this forum.  I haven't looked closely enough to confirm that this
> is the problem in your case, but it seems likely.

Yeah, the EXPLAIN ANALYZE output clearly shows a drastic underestimate
of the number of rows out of a join like this, and a consequent choice
of a nestloop above it that performs terribly.

> 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.

			regards, tom lane