Tom Lane wrote:
>"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.
>
>
Interesting, so the postmaster would kick off an autovacuum process,
which would read in data from the stats system by hand ( it can do this
because the stat system writes it's data to flat files?). I don't know
how complicated this might be but perhaps a simpler method is to just
have each autovacuum process write a file for itself noting what
database it should connect to next. This would work find assuming we
want to continue to loop through all the databases in much the same
fashion as pg_autovacuum currently does.
>>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.
>>
>>
>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...
>
Ok.