On Sun, 21 Mar 2004, Matthew T. O'Connor wrote: > On Sun, 2004-03-21 at 20:31, Christopher Kings-Lynne wrote: > > > I think these configuration issues will become a lot easier if you make > > > the autovacuum daemon a subprocess of the postmaster (like, say, the > > > checkpoint process). Then you have access to a host of methods for > > > storing state, handling configuration, etc. > > > > Yeah - why delay making it a backend process? :) > > Ok, well this was part of the reason to have this conversation. > > My reasons: > A) I wasn't sure if people really thought this was ready to be > integrated. Tom had said a while ago, that it was a good to keep it as > a contrib module while it's still actively being developed.
I was talking to Jan about some other work on VACUUM related to more intelligent vacuuming. Namely, maintaining a map (outside of shared memory) of blocks which have been pushed out of the free space map for VACUUM to visit (which requires a backend process) and being aware of load restrictions (ie, allowing user to only vacuum when the load average is less than X, for example) and some other leveling stuff to ensure that availability is consistent. Whilst this doesn't related to pg_autovacuum specifically, it'd be great if they could be released at the same time, I think. > > B) Perhaps people like the idea of it being a client app (I don't think > so.) > I'd like to see it as part of the backend. > C) Most importantly, I'm not backend hacker. If someone wants to do the > initial work of getting it running as a backend process, I can take it > from there. A while ago, Bruce offered to help me with any backend > issues I might have, so perhaps with a little help I can take a run at > it. I'd be happy to help you out. Gavin ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html