Re: pg_autovacuum next steps

"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
> There are differing opinions as to the best way to providing these this
> feature. The primary debate is where to save the configuration data. I
> see three options:

> 1.Store config data inside a special pg_autovacuum table inside
> existing databases that wants custom settings.

> 2.Use a config file. This would require some additional coding to add
> the required parsing, but is possible.

> 3.Create a pg_autovacuum database inside any cluster that wants to
> customize their settings.

> Since many people do not like tools that clutter their databases by
> adding tables, I think option 1 (adding a pg_autovacuum table to
> existing databases) is right out. Using a config file would be Ok, but
> would require additional parsing code. My preference is option 3.

Personally I like #2. The claim that this requires extra code seems
bogus to me --- when you are working at the C code level, reading a
table takes code too. I think both 1 and 3 represent clutter. Also,
they will introduce entirely new sets of problems that we already know
how to deal with in the case of config files, but have no experience
with for config tables. Some examples: how do you get the daemon to
notice that you changed the config (SIGHUP for config files, ??
otherwise)? Can you easily get at the config data from a daemon process
regardless of which database it's attached to (if any)? If the config
data is in a table, what sorts of interesting problems will arise from
trying to vacuum that table itself?

Basically I see config tables as cutting against the grain of everything
we've done to date in Postgres DBA-level configuration, and I do not see
a reason to justify that sort of reinvention.

regards, tom lane