Re: Planner having way wrong estimate for group aggregate

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Planner having way wrong estimate for group aggregate
Дата
Msg-id 7261.1095536893@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Planner having way wrong estimate for group aggregate  ("Steinar H. Gunderson" <sgunderson@bigfoot.com>)
Ответы Re: Planner having way wrong estimate for group aggregate
Список pgsql-performance
"Steinar H. Gunderson" <sgunderson@bigfoot.com> writes:
> Now, my first notion was creating a functional index to help the planner:
> ...
> However, this obviously didn't help the planner (this came as a surprise to
> me, but probably won't come as a surprise to the more seasoned users here :-)

7.4 doesn't have any statistics on expression indexes.  8.0 will do what
you want though.  (I just fixed an oversight that prevented it from
doing so...)

> Actually, it seems that the higher I set statistics on "tid", the worse the
> estimate becomes.

I believe that the estimate of number of groups will be exactly the same
as the estimate of the number of values of tid --- there's no knowledge
that date_trunc() might reduce the number of distinct values.

> Any ideas for speeding this up?

In 7.4, the only way I can see to force this to use a hash aggregate is
to temporarily set enable_sort false or raise sort_mem.

            regards, tom lane

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

Предыдущее
От: Shachar Shemesh
Дата:
Сообщение: Re: Tryint to match Solaris-Oracle performance with directio?
Следующее
От: "Steinar H. Gunderson"
Дата:
Сообщение: Re: Planner having way wrong estimate for group aggregate