From: "Tom Lane" <[EMAIL PROTECTED]> > "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes: > > I chose to leave pg_autovacuum simple and not add too many features because > > the core team has said that it needs to be integrated into the backend > > before it can be considered a core tool. > > I think actually it makes plenty of sense to enhance pg_autovacuum while > it's still contrib stuff. My guess is it'll be much less painful to > whack it around in minor or major ways while it's standalone code. > Once it's integrated in the backend, making significant changes will be > harder and more ticklish. So, now is precisely the time to be > experimenting to find out what works well and what features are needed.
Fair point, my only concern is that a backend integrated pg_autovacuum would be radically different from the current libpq based client application. When integrated into the backend you have access to a lot of information that you don't have access to as a client. I know one goal I have for the backend version is to be based on the FSM and not require the stats collector since it has a measurable negative effect on performance. But in the more general sense of learning what features people want (exclusion lists, per table defaults etc) I agree the current version is a sufficient testing ground. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly