On Mon, 22 Mar 2004, Tom Lane wrote:
> "Matthew T. O'Connor" <matthew@zeut.net> writes:
> > Well this certainly sounds like something that would be easy to do,
> > which appeals to me at least as a first cut. Question: Does this mean
> > that I lose many of the advantages of being "in the backend"? That is,
> > would pg_autovacuum still be able to use facilities such as GUC, error
> > reporting, access to the FSM, direct pipe connection to the stats
> > collector etc?
>
[snip]
> The more I think about this the more I like it --- it keeps the autovac
> control code still at arms length from the backend which will surely
> ease development and experimentation. I suppose there is some overhead
> in pushing data back and forth over the FE/BE protocol, but surely that
> would be negligible next to the "real work" of vacuuming.
I was initially against the idea of using libpq but its growing on me too.
I think it would be good if the core functions of pg_autovacuum: threshold
algorithms, connection, issuing commands can be (re?)designed such that
not only the backend can link against it but also a stripped down
pg_autovacuum binary which can be used manually. That way users can have a
choice and a workaround if there are any issues with the backend model.
Also useful for debugging.
Thanks,
Gavin
