"Joshua D. Drake" <jd@commandprompt.com> writes:
> Your objection is let's keep it as difficult as possible within the
> existing paradigm because nobody thought pg_autovacuum could be useful
> in the first place.
No, my point is that there's no value in putting band-aids on an object
that was never designed to be user-friendly. The extra ease of use from
putting defaults on that table's columns is insignificant compared to
what we'd get by fixing its *real* problems:
* superuser-only, no mechanism to let users admin their own tables (nor any way to reconcile user-set values with a
DBA'spossible wish to override them)
* no support for dumping and restoring settings
I don't think we should be encouraging direct manual insertions into
pg_autovacuum in any case.
So I'd rather see some effort spent on figuring out what the API really
*should* look like. I don't know, other than that it should hard-wire
as little as possible because we are likely to be changing the set of
available parameters in future. Maybe we need a concept like per-table
settings for GUC variables?
regards, tom lane
