On Mon, 22 Mar 2004, Tom Lane wrote: > "Matthew T. O'Connor" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
