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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
Дата
Msg-id 11894.1368477199@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-performance
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 13, 2013 at 4:14 PM, Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-performance по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
Следующее
От: Marti Raudsepp
Дата:
Сообщение: Re: statistics target for columns in unique constraint?