Gavin Sherry <[EMAIL PROTECTED]> writes:
> One point is this: vacuum() assumes that you are running in a fully
> fledged backend. There'd be a fair bit of work involved in allowing a
> single process to call vacuum() against multiple databases.
Make that "it isn't going to happen".
> 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.
regards, tom lane
---------------------------(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
