Re: postmaster consuming /lots/ of memory with hash aggregate. why?

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: postmaster consuming /lots/ of memory with hash aggregate. why?
Дата
Msg-id AANLkTi=_igsVFkEg2H=90_aJpCrA2Q9FSFurTyLLu74m@mail.gmail.com
обсуждение исходный текст
Ответ на Re: postmaster consuming /lots/ of memory with hash aggregate. why?  (Jon Nelson <jnelson+pgsql@jamponi.net>)
Ответы Re: postmaster consuming /lots/ of memory with hash aggregate. why?  (Jon Nelson <jnelson+pgsql@jamponi.net>)
Список pgsql-performance
2010/11/12 Jon Nelson <jnelson+pgsql@jamponi.net>:
> On Thu, Nov 11, 2010 at 10:26 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> Hello
>>
>> look on EXPLAIN ANALYZE command. Probably your statistic are out, and
>> then planner can be confused. EXPLAIN ANALYZE statement show it.
>
> As I noted earlier, I did set statistics to 1000 an re-ran vacuum
> analyze and the plan did not change.

this change can do nothing. this is default in config. did you use
ALTER TABLE ALTER COLUMN SET STATISTIC = ... ? and ANALYZE

>
> What other diagnostics can I provide? This still doesn't answer the
> 40000 row question, though. It seems absurd to me that the planner
> would give up and just use 40000 rows (0.02 percent of the actual
> result).
>

there can be some not well supported operation, then planner use a
some % from rows without statistic based estimation

Pavel
> --
> Jon
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

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

Предыдущее
От: Jon Nelson
Дата:
Сообщение: Re: postmaster consuming /lots/ of memory with hash aggregate. why?
Следующее
От: Cédric Villemain
Дата:
Сообщение: Re: anti-join chosen even when slower than old plan