"Joshua D. Drake" <[EMAIL PROTECTED]> 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's possible
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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
