Re: pg_autovacuum next steps

"Matthew T. O'Connor" <matthew(at)zeut(dot)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?

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