Re: pg_autovacuum next steps

> > As such, I
> > think that a vacuum backend for a specific database should be forked upon
> > the first connect. Also, the backend might like to try and workout if
> > there are any active backends for its database every so often and if not,
> > perform a final vacuum (if necessary) and exit, so that we don't have lots
> > of idle processes sitting around.
>
> Lots of idle processes sitting around is right out, too. Remember that
> each one would eat a backend connection slot. I think we are going to
> have to limit this to *one* process at a time. What that probably means
> is that we successively launch an autovacuum process against each
> database, it does whatever seems appropriate in that database and then
> quits. We could manage this just like checkpoints are presently managed
> --- the only thing the postmaster has to know is the desired idle period
> between end of one autovacuum and start of the next.

*slaps hand on forehead*

Yes, this is the best approach.

So, do we want a static time, a GUC controlled time or some time which is
modified by pg_autovacuum's/stat's collector's knowledge of the amount of
work which goes on in any given database?

Gavin