On Fri, Feb 23, 2007 at 06:47:52PM -0500, Tom Lane wrote: > 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. Actually, if we wanted to we should be able to create a view that takes the place of the current pg_autovacuum. With appropriate rules and some functions, you could probably even make it updatable. -- Jim Nasby jim@xxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
