Re: pg_autovacuum next steps

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