Re: Autovacuum to-do list

Поиск
Список
Период
Сортировка
От Gavin Sherry
Тема Re: Autovacuum to-do list
Дата
Msg-id Pine.LNX.4.58.0507281034240.32271@linuxworld.com.au
обсуждение исходный текст
Ответ на Autovacuum to-do list  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Autovacuum to-do list  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On Wed, 27 Jul 2005, Alvaro Herrera wrote:

> Hackers,
>
> This is a list of things people mentioned as interesting to do for
> vacuum/autovacuum, during the last autovacuum discussion thread.  Some
> of them are wishful thinking, others are doable.
>
> Neil, Gavin: both of you mentioned that you didn't like autovacuum as a
> long term solution.  May I ask you if you have more suggestions for this
> list?

My argument against autovacuum integration was more about the fact that we
shouldn't automate vacuuming in the backend until the cost of vacuum
reduces significantly. The fact is that it has been integrated so I think
the following might be worth considering:

* Change how we track the need to vacuum
I don't really think the use of row level stats are the bestindicator for a need to vacuum. I wonder if we could keep
acounterfor each segment (ie, every 1 GB file backing a heap orindex) or file which indicates the number of blocks
whichhave beendirtied since the last vacuum. The user would specify a thresholdof X blocks and once we reached that we
wouldinvoke vacuum.
 
This means we can do without row level stats, I think, at theexpense of having to maintain state in shared memory for
eachtableand index (or segment). I'm not sure if that is a goodtrade off or not but it reminds me of counting cards in
blackjack--and good things always come of that ;-).
 

That's all I can think of at the moment.

Thanks,

Gavin


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

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: Some new list.c primitives
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: [Testperf-general] dbt2 & opteron performance