Re: pg_autovacuum next steps

On Mon, 2004-03-22 at 03:36, Gavin Sherry wrote:
> 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.

I can't imagine we want to do that.

> 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.

I don't understand, are you saying that upon postmaster startup a vacuum
backend should be forked for every database in the cluster?

> Is there a better approach than this?

One thought I had is that there wouldn't be a persistent daemon type
process, rather the auto_vacuum process, like the check point process,
would be kicked off periodically, it would initially be attached to
template1, then when it's done there it will figure out the next
database to take a look at and fork, the existing template1 process will
exit, and the new process will be connected to the next database, just
repeat this forking loop until done.

Thoughts?