After a long battle with technology, [EMAIL PROTECTED] (Josh Berkus), an earthling, 
wrote:
>> As long as pg_autovacuum remains a contrib module, I don't think
>> any changes to the system catelogs will be make.  If pg_autovacuum
>> is deemed ready to move out of contrib, then we can talk about the
>> above.
>
> But we could create a config file that would store stuff in a
> flatfile table, OR we could add our own "system table" that would be
> created when one "initializes" pg_avd.

The problem with introducing a "config file" is that you then have to
introduce a language and a parser for that language.

That introduces rather a lot of complexity.  That was the BIG problem
with pgavd (which is a discarded project; pg_autovacuum is NOT the
same thing as pgavd).  There was more code involved just in managing
the pgavd parser than there is in all of pg_autovacuum.

I think the right answer for more sophisticated configuration would
involve specifying a database in which to find the pg_autovacuum
table(s).

> Just an idea.  Mind you, I'm not so sure that we want to focus
> immediately on per-table settings.  I think that we want to get the
> "automatic" settings working fairly well first; a lot of new DBAs
> would use the per-table settings to shoot themselves in the foot.
> So we need to be able to make a strong recommendation to "try the
> automatic settings first."

Yeah, it's probably a good idea to ensure that per-table settings
involves some really conspicuous form of "foot gun" (with no kevlar
socks) to discourage its use except when you _know_ what you're
doing...
-- 
let name="cbbrowne" and tld="ntlug.org" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
Q: Can SETQ only be used with numerics?
A: No, SETQ may also be used by Symbolics, and use it they do.

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

Reply via email to