Re: Updating histogram_bounds after a delete

Поиск
Список
Период
Сортировка
От Derrick Rice
Тема Re: Updating histogram_bounds after a delete
Дата
Msg-id AANLkTinJ7SfPYJrKdnMXr4WZVTPWyomRW8C+i87XQJht@mail.gmail.com
обсуждение исходный текст
Ответ на Updating histogram_bounds after a delete  (Derrick Rice <derrick.rice@gmail.com>)
Список pgsql-performance
Oh, I'm using 8.2

On Wed, Mar 16, 2011 at 3:40 PM, Derrick Rice <derrick.rice@gmail.com> wrote:
Greetings.

I recently ran into a problem with a planner opting for a sequential scan rather than a bitmap heap scan because the stats suggested that my delete query was going to affect 33% of the rows, rather than the 1% it really was.  I was able to follow the planner's logic and came to the realization that it was a result of the histogram_bounds for that column being out of date.

The table is regularly purged of some of it's oldest data, and new data is constantly added.  It seems to me that PostgreSQL *should* be able to identify a query which is going to delete all rows within a histogram bucket, and could possibly react by updating the histogram_bounds at commit-time, rather than needing an additional analyze or needing auto-analyze settings jacked way up.

Alternatively, it might be nice to be able to manually describe the table (I've been following the "no hints" discussion) by providing information along the lines of "always assume that column event_date is uniformly distributed".  This would be provided as schema information, not additional SQL syntax for hints.

Is this something that is remotely feasible, has the suggestion been made before, or am I asking for something where a solution already exists?

Thanks,

Derrick

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

Предыдущее
От: Derrick Rice
Дата:
Сообщение: Updating histogram_bounds after a delete
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Re: Adding additional index causes 20,000x slowdown for certain select queries - postgres 9.0.3