"Matthew T. O'Connor" <matthew@zeut.net> writes:
> I don't think you can use a dump to determine who should be connected to
> next since you don't really know what happened since the last time you
> exited. What was a priority 5 or 10 minutes ago might not be a priority
> now.
Well, the information necessary to make that decision has to be
available from the statistics file. This doesn't seem like an
insuperable problem.
> The rough design I had in mind was:
> 1) On startup postmaster spawns the master autovacuum process
> 2) The master autovacuum process spawns backends to do the vacuuming
> work on a particular database
> 3) The master autovacuum waits for this process to exit, then spaws the
> next backend for the next database
> 4) Repeat this loop until all databases in the cluster have been
> checked, then sleep for a while, and start over again.
This is unworkable, I believe, because backends have to be direct
children of the postmaster. I don't recall the details at the moment
but there are IPC signaling reasons for it.
> I'm not sure if this is feasible, or if this special master autovacuum
> process would be able to fork off or request that the postmaster fork
> off an autovacuum process for a particular database in the cluster.
> Thoughts or comments?
It's possible that we could add some signaling whereby the autovac
master could request the postmaster to fork a child into a particular
database. I'm not sure why this is a lot better than keeping the
stats out where everyone can see them...
regards, tom lane
