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?
|
Список | 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 по дате отправления: