Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Christoph Berg <christoph(dot)berg(at)credativ(dot)de>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
Date: 2013-05-13 20:33:19
Message-ID: 11894.1368477199@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, May 13, 2013 at 4:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Marti Raudsepp 2013-05-13 22:10:06 Re: statistics target for columns in unique constraint?
Previous Message Robert Haas 2013-05-13 20:29:29 Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1