"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 ---------------------------(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