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                                            [EMAIL PROTECTED]
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to