"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?
If you aren't a backend then you couldn't safely access shared memory, including FSM in particular. I see no reason you couldn't use GUC though. There is no "direct pipe connection" to the stats collector, except in the output direction which is not what you want, so I'm not seeing your point there. I am not sure that lack of FSM access is a showstopper, though. We could easily imagine inventing backend commands to read out whatever info you want from FSM, so you could request the info from your connected backend. 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])