Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
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
It might be good to ship 8.1 without them since autovacuum might change
a fair amount between 8.1 and 8.2 (FSM integration, better formula for
vacuum decisions etc...)
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.
If memory serves from development discussion of the contrib version,
isn't there an issue that while a shared relation need only be vacuumed
in one database in order to reclaim space etc, the analyze statistics
need to be updated in each database. Does that ring a bell or am I way
off base here?
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings