I wrote:
> I don't find this particularly important, because we have never intended
> direct update of catalog entries to be a primary way of interacting with
> the system. The current pg_autovacuum setup is a stopgap until the dust
> has settled enough that we know what sort of long-term API we want for
> autovacuum.
I just had an epiphany about that. We've wanted to avoid setting the
autovacuum knobs in stone, because it's pretty obvious they're not
ready, and that has prevented us from inventing any nice SQL syntax for
managing the per-table settings.
Meanwhile, the storage-parameter infrastructure got added in 8.2.
Isn't that an absolutely ideal framework for managing per-table autovac
settings? We could drop the separate pg_autovacuum catalog altogether
and keep all the info in pg_class.reloptions. Advantages:
* The infrastructure is all there already, including ALTER TABLE and
pg_dump support.
* The parameter names are not SQL keywords, and the syntax isn't
hardwired to any particular set of them. So it would be fairly painless
to change the set of supported parameters, with or without backwards
compatibility to keep on recognizing an old parameter.
Disadvantages:
* Wouldn't be forwards-compatible with any hacks that people might
currently have to dump and restore pg_autovacuum contents. But you
could probably make a script to read your existing table and emit
ALTER TABLE SET commands instead.
regards, tom lane