Autovacuum to-do list

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?

* Enable autovacuum by default.
 Get some field experience with it first, so the worst bugs are covered. (Has anybody tested it?)

* Add per-table vacuum delay parameters.

* Integrate the FSM with autovacuum.
 Maybe invent the concept of a "dead space map".  This could be a bitmap per heap segment, where we keep a bit set for
eachpage in the segment that has dead tuples.
 

* Make the decision taking about what database to vacuum be smarter.
 Right now, we only consider what database was least recently vacuumed. We could have a per-database counter of dead
tuplesin pgstats; we have to figure out a way to use that and not cause starvation for less-used databases.
 

* Make XID wraparound issues be determined on a per-table basis.

* Implement some sort of maintenance window where vacuum policy would be more aggresive.  Maybe the reverse: specify
somehours at which vacuum should not run at all.  One alternative for this is to suggest changing autovacuum parameters
froma script to be run by cron or pgAgent.
 

* Implement partial vacuums.
 A partial vacuum would scan only a portion of the table looking for dead tuples, then stop.  Or maybe not partial, but
insteadvacuum a portion, then stop, release locks, sleep for a while, then continue with the rest.
 

* Have autovacuum daemons per-database or per-tablespace.

* Use REINDEX instead of updating the index for each tuple, if the dead tuple count is too high.

* Stop a running VACUUM if the system load is too high.

-- 
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"La verdad no siempre es bonita, pero el hambre de ella sí"