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

pg_autovacuum Integration

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: pg_autovacuum Integration
Date: 2004-05-28 18:20:32
Message-ID: 18077.192.154.91.225.1085768432.squirrel@192.154.91.225 (view raw or flat)
Thread:
Lists: pgsql-hackers
Since the Feature Freeze is coming on quickly and I have yet to submit a
patch that integrated pg_autovacuum into the backend (though I have been
working on it), I wanted to see what people thing about a few things.

Since we are nearing feature freeze, I know won't complete all the
improvements to pg_autovacuum that are on my list, so I need to
prioritize.

Here is what I would like to do (in order of decreasing prioity for 7.5):

(Please pardon any minor inaccuracies as I am stuck at a clients office
where I don't have access to postgresql src)

1) Move pg_autovacuum from: /contrib/pg_autovacuum/ to:
/src/bin/pg_autovacuum/
This can be done immediately with only a minor change to the Makefile.
Since people seem to be pleased with pg_autovacuum and want it integrated
into th backend, I think it is safe to move it out of contrib.  Do people
agree?

2) Once pg_autovacuum is moved into /src/bin (formally included into the
project) then I want to add a few columns to the system tables (pg_class?)
that will store the data pg_autovacuum needs to remember what was
happening the last time it was running (This is just the insert, update
and delete counts from the stats system at the time of the last known
vacuum).  For 7.5 pg_autovacuum will update these values, however it will
be much better if the vacuum and analyze commands themselves update these
values, that way pg_autovacuum won't do any work on a table that was
recently vacuumed manually.

3) Modify the postmaster to launch and kill pg_autovacuum according to a
new GUC variable.


Obviously there is a lot more on the todo list for pg_autovacuum, but the
3 steps described above would make a significant improvement.  Does that
sounds reasonable?

Matthew O'Connor

pgsql-hackers by date

Next:From: Manfred KoizarDate: 2004-05-28 18:29:51
Subject: Re: SELECT * FROM <table> LIMIT 1; is really slow
Previous:From: Bruce MomjianDate: 2004-05-28 18:08:09
Subject: Re: Win32, PITR, nested transactions, tablespaces

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