From: "Tom Lane" <tgl@sss.pgh.pa.us>
> "Matthew T. O'Connor" <matthew@zeut.net> 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.
