Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UbzQz-0005it-Ma for pgsql-performance@arkaria.postgresql.org; Mon, 13 May 2013 20:33:25 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UbzQy-00039G-Gt for pgsql-performance@arkaria.postgresql.org; Mon, 13 May 2013 20:33:24 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UbzQx-00039B-Nx for pgsql-performance@postgresql.org; Mon, 13 May 2013 20:33:23 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UbzQv-0006Ne-RV for pgsql-performance@postgresql.org; Mon, 13 May 2013 20:33:23 +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 r4DKXJg8011895; Mon, 13 May 2013 16:33:19 -0400 (EDT) From: Tom Lane To: Robert Haas cc: Christoph Berg , PostgreSQL Performance Subject: Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1 In-reply-to: References: <20130430112055.GA27525@msgid.df7cb.de> <11475.1368476046@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Mon, 13 May 2013 16:29:29 -0400" Date: Mon, 13 May 2013 16:33:19 -0400 Message-ID: <11894.1368477199@sss.pgh.pa.us> X-Pg-Spam-Score: -0.6 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Robert Haas writes: > On Mon, May 13, 2013 at 4:14 PM, Tom Lane wrote: >> 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 ... > Yeah, I remember there have been examples like this that have come up > before. Unfortunately, I haven't fully grokked what's actually going > on here that allows this kind of thing to happen. Refresh my memory > on where the relevant code is? The point is that we estimate the size of a joinrel independently of any particular input paths for it, and indeed before we've built any such paths. So this seems like a bug somewhere in selectivity estimation, but I'm not prepared to speculate as to just where. 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