Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from
	<pgsql-performance-owner+M49841=pgsql-performance-ar@postgresql.org>)
	id 1Ubz8Q-0004Vk-8g for pgsql-performance@arkaria.postgresql.org;
	Mon, 13 May 2013 20:14:14 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
	by malur.postgresql.org with smtp (Exim 4.72) (envelope-from
	<pgsql-performance-owner+M49841=pgsql-performance-ar@postgresql.org>)
	id 1Ubz8P-0007BV-Jy for pgsql-performance@arkaria.postgresql.org;
	Mon, 13 May 2013 20:14:13 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <tgl@sss.pgh.pa.us>) id 1Ubz8O-0007BQ-Sx
	for pgsql-performance@postgresql.org; Mon, 13 May 2013 20:14:12 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <tgl@sss.pgh.pa.us>) id 1Ubz8L-00067X-T5
	for pgsql-performance@postgresql.org; Mon, 13 May 2013 20:14:12 +0000
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r4DKE6Wo011476;
	Mon, 13 May 2013 16:14:06 -0400 (EDT)
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Christoph Berg <christoph.berg@credativ.de>,
	PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: RT3.4 query needed a lot more tuning with 9.2 than it did with
 8.1
In-reply-to: 
 <CA+Tgmobe3UH50Uhq=NLFj5GvgMgq2qMohguhOFBqhEgcMtKx=w@mail.gmail.com>
References: <20130430112055.GA27525@msgid.df7cb.de>
	<CA+Tgmobe3UH50Uhq=NLFj5GvgMgq2qMohguhOFBqhEgcMtKx=w@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 13 May 2013 15:58:50 -0400"
Date: Mon, 13 May 2013 16:14:06 -0400
Message-ID: <11475.1368476046@sss.pgh.pa.us>
X-Pg-Spam-Score: -2.5 (--)
List-Archive: <http://archives.postgresql.org/pgsql-performance>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-performance.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@postgresql.org>
List-Post: <mailto:pgsql-performance@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-performance>
List-Unsubscribe: 
 <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
X-Mailing-List: pgsql-performance
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Robert Haas <robertmhaas@gmail.com> writes:
> The planner is estimating this the outer side of this nested loop will
> produce 33 rows and that the inner side will produce 1.  One would
> assume that the row estimate for the join product couldn't be more
> than 33 * 1 = 33 rows, but the planner is estimating 62335 rows, which
> seems like nonsense.

You know, of course, that the join size estimate isn't arrived at that
way.  Still, this point does make it seem more like a planner bug and
less like bad input stats.  It would be nice to see a self-contained
example ...

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance