Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
В списке pgsql-performance по дате отправления:
| От | 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
|
| Список | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера