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
Дата
Msg-id CA+TgmoZ3PaO23NNvKfn1CQm2c7xCfsLX9=94pm0=6t9UCC6Edw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Mon, May 13, 2013 at 4:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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 ...

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?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: 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