Re: Autovacuum to-do list - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: Autovacuum to-do list
Date
Msg-id Pine.LNX.4.58.0507281034240.32271@linuxworld.com.au
Whole thread Raw
In response to Autovacuum to-do list  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Autovacuum to-do list
List 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 by date:

Previous
From: Neil Conway
Date:
Subject: Re: Some new list.c primitives
Next
From: Josh Berkus
Date:
Subject: Re: [Testperf-general] dbt2 & opteron performance