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: | 20050728002254.GS1832@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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í"
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2005-07-28 00:25:32 | Re: Some new list.c primitives |
Previous Message | Tom Lane | 2005-07-28 00:12:10 | Re: Sanity Check? |