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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

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