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

Autovacuum integration patch

From: Alvaro Herrera <alvherre(at)surnet(dot)cl>
To: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Autovacuum integration patch
Date: 2005-06-29 22:32:45
Message-ID: 20050629223245.GA25349@surnet.cl (view raw or flat)
Thread:
Lists: pgsql-patches
Hackers,

Here is a first cut at autovacuum integration.  Please have a look at
it.  Note that this patch automatically creates three new files:

src/backend/postmaster/autovacuum.c
src/include/catalog/pg_autovacuum.h
src/include/postmaster/autovacuum.h

Note that the daemon is not activated by default.

There are several things that are painfully evident with this thing on:

- TRUNCATE does not update stats.  It should send a stat message to
  which we can react.

- If you empty a whole table using DELETE just after an
  automatically-issued VACUUM takes place, the new threshold may not be
  enough to trigger a new VACUUM.  Thus you end up with a bloated table,
  and it won't get vacuumed until it grows again.  This may be a problem
  with the cost equations, but those are AFAICT identical to those of
  pg_autovacuum, so we may need to rethink the equations.

- The default value of on for reset stats on server start is going to be
  painful with autovacuum, because it reacts badly to losing the info.

- We should make VACUUM and ANALYZE update the pg_autovacuum relation,
  in order to make the autovacuum daemon behave sanely with manually
  issued VACUUM/ANALYZE.

- Having an autovacuum process running on a database can be surprising
  if you want to drop a database, or create a new one using it as a
  template.  This happenned to me several times.

- The shutdown sequence is not debugged nor very well tested.  It may be
  all wrong.

- The startup sequence is a mixture from pgarch, normal backend and
  pgstat.  I find it relatively clean but I can't swear it's bug-free.

- There are no docs

- There are no ALTER TABLE commands to change the pg_autovacuum
  attributes for a table. (Enable/disable, set thresholds and scaling
  factor)

- I compiled with -DEXEC_BACKEND, but I didn't look to see if it
  actually worked on that case.

Apart from all these issues, it is completely functional :-)  It can
survive several "make installcheck" runs without problem, and the
regression database is vacuumed/analyzed as it runs.

Some of these issues are trivial to handle.  However I'd like to release
this right now, so I can go back to "shared dependencies" now that role
support is in.

Barring any objections I think this should be integrated, so these
issues can be tackled by interested parties.

-- 
Alvaro Herrera (<alvherre[a]surnet.cl>)
"World domination is proceeding according to plan"        (Andrew Morton)

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2005-06-29 23:00:04
Subject: Re: [HACKERS] Dbsize backend integration
Previous:From: Andreas PflugDate: 2005-06-29 21:42:33
Subject: Re: [HACKERS] Dbsize backend integration

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