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
