Re: [HACKERS] Autovacuum loose ends

On Thu, Jul 14, 2005 at 10:52:56AM -0400, Tom Lane wrote:
> I've applied Alvaro's latest integrated-autovacuum patch.  There are
> still a number of loose ends to be dealt with before beta, though:

Ok, here's a patch that deals with some of this:

- The stat collector is modified so as to keep shared relations separate
  from regular ones.  Also, backends sends messages separately.
  Autovacuum takes advantage of this, so it correctly identifies the
  appropiate time to operate on a shared relation, irrespective of the
  database where they were modified.  Note however that it uses each
  database's pg_autovacuum settings.  This means it could be vacuumed
  sooner in one database than another, but I don't think it's a problem.

- Temp tables are completely ignored.

- pg_statistic is completely ignored.

- databases with no stat entry are still ignored, except that they are
  checked for Xid wraparound like any other.  The "oldest" one is chosen
  for vacuum in a particular autovacuum run.

- A database-wide vacuum forces a pg_database flat-file update, so that
  the wraparound check actually works.

- The postmaster's main loop sleeps Min(60, autovacuum_naptime), in
  order to be able to pick naptimes smaller than 60 seconds.  In order
  not to make the loop a busy-wait, I forced a minimum of 1 to that GUC
  var.



Some comments:

- Now that we have a real Xid wraparound check, we could go back to
  having any table with no stat entry ignored, which was the original
  coding.  There's no danger of wraparound, and there'd be no work done
  to a table that doesn't have any activity.  We have to consider what
  happens at stat reset -- AFAICS there's no problem, because as soon as
  the table sees some activity, it will be picked up by pgstat.
  However, it would be bad if stats are reset right after some heavy
  activity on a table.  Maybe the only thing we need is documentation.

- datallowcon is still ignored.  Now it's safe to do so, because we have
  a real Xid wraparound check.  Changing it requires extending the
  pg_database flat-file (should be fairly easy).

- There are stat messages emitted for a database-wide vacuum, just like
  any other.  This means that all tables in the database would end up in
  pgstat; and also all databases, including those with datallowconn = false.
  This may not be good.  I'm not sure what exactly to do about it.  Do
  we want to disallow such stats?  Disable message sending (or
  collecting) in some circumstances?

- I haven't done anything yet w.r.t. the custom vacuum_delay nor sleep
  scale factor.

- There are still no docs.


--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Porque Kim no hacia nada, pero, eso sí,
con extraordinario éxito" ("Kim", Kipling)