Re: pg_autovacuum next steps

On Mon, 2004-03-22 at 10:51, Tom Lane wrote:
> > 2.Use a config file. This would require some additional coding to add
> > the required parsing, but is possible.
>
> 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?

I guess what I mean by extra code is extra work since I am comfortable
storing data in tables, and would need to do some work to put it in a
config file.

Some of this conversations should change if we really are going to
integrate autovacuum into the backend. My suggestions for storing
config data was really assuming that we would continue to be a client
app for at least one more release cycle, but I think I'm hearing that
people want it in the backend now.

Assuming that we are being integrated into the backend, and assuming
that a autovacuum process is fired off periodically by the postmaster, I
think some config items should become GUC options and others will become
part of the system tables. For example: enable_autovacuum should be a
GUC option, but the vacuum threshold for a given table should probably
just be a new column in the pg_class table. Any data stored in the
system tables will be check every time the autovacuum process is run so
there won't be any problems with noticing that the admin change the
threshold for a given table.

> 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.

I agree if we are talking about a client app, but I think the scheme
laid out above is consistent for something that is part of the backend,
do you disagree?

Thanks,

Matthew O'Connor