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
