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 11475.1368476046@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:
> 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


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

Предыдущее
От: "Mark Felder"
Дата:
Сообщение: Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
Следующее
От: Robert Haas
Дата:
Сообщение: Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1