Skip site navigation (1) Skip section navigation (2)

Autovacuum to-do list

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Autovacuum to-do list
Date: 2005-07-28 00:22:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-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

* 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

* 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]>)
"La verdad no siempre es bonita, pero el hambre de ella sí"


pgsql-hackers by date

Next:From: David FetterDate: 2005-07-28 00:25:32
Subject: Re: Some new list.c primitives
Previous:From: Tom LaneDate: 2005-07-28 00:12:10
Subject: Re: Sanity Check?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group