Re: R: R: slow seqscan after vacuum analize

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: R: R: slow seqscan after vacuum analize
Дата
Msg-id 4193.1076000989@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: R: R: slow seqscan after vacuum analize  (Christopher Browne <cbbrowne@acm.org>)
Ответы Drop indexes inside transaction?  (Steve Lane <slane@moyergroup.com>)
Список pgsql-admin
Christopher Browne <cbbrowne@acm.org> writes:
> Another factor worth considering: If a few values are very common in
> the field you are selecting on, then the query optimizer can get
> convinced (wrongly) that a Seq Scan is the best choice.  Using ALTER
> TABLE T ALTER COLUMN C SET STATISTICS [some value] to increase the
> number of "bins" can be helpful in such cases.  (My pet theory is that
> the present default value of 10 is a little low, and that a lot of
> optimizer errors might be resolved by bumping it up a bit...)

I also suspect that 10 is a lowball figure, but no one has done any work
to establish what might be a more reasonable default.  Larger values
have real costs in both pg_statistic space and planner runtime, so I
don't want to push it up without some kind of evidence.

BTW, if you think a higher default might be appropriate, you can set it
in postgresql.conf instead of running around and manually ALTERing all
your tables.

            regards, tom lane

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

Предыдущее
От: "Stefan Sturm"
Дата:
Сообщение: VACUUM Quesition
Следующее
От: Sam Barnett-Cormack
Дата:
Сообщение: Re: VACUUM Quesition