> > 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 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match