Re: Autovacuum integration

Tom Lane wrote:

>Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 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
>without 'em.
>
>

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?