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 each page 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 tuples in 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 some hours at which vacuum should not run at all. One alternative for this is to suggest changing autovacuum parameters from a 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 instead vacuum 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í" ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org