Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On Fri, Jul 08, 2005 at 03:56:25PM -0400, Tom Lane wrote:
>> pg_autovacuum should only contain user-settable parameters ---
> Ok. Do you think it's worth the trouble to have ALTER TABLE commands to
> change autovac parameters?
I think we'll want them eventually, but I don't mind if 8.1 ships
without 'em.
>> * I see you have an autovac_init function to "annoy the user", but
>> shouldn't this be checked every time we are about to spawn an autovac
>> process?
> You argued exactly the other way around to Matthew, before 8.0 freeze.
Did I? I've forgotten the reasoning if so. But it's a minor point.
> Yeah. The problem with this is that any particular database could be
> absent from the stat hash. Personally I think we should make the stat
> system aware of all databases, whether there has been activity in them
> or not. That'd make this problem moot, and we could skip those tables
> in any databases except template1.
Hm. There's nothing wrong with having CREATE DATABASE send a message to
pgstats, but that could get lost anyway. A probably more significant
point is that either postgres or template1 is subject to being dropped;
so hardwiring a single database to do it from is likely not gonna work.
It'd be okay to *consider* vacuuming the shared relations on every
cycle, so long as the stats were managed correctly (ie, only one set of
stats kept). This is probably easier to do in the context of the
stats-in-pgstats idea than before. We could have pgstats deliberately
create an entry for "database zero", and put the table stats for shared
relations there. The only real issue is that we have no place to keep
any nondefault parameters for these catalogs (no, I don't wish to invent
pg_shautovacuum to fix that ;-)) so they'd always be autovacuumed with
the global default parameters. This seems acceptable to me.
regards, tom lane