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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)