On Sunday 14 January 2007 05:18, Alvaro Herrera wrote:
> I've been thinnking how to improve autovacuum so that we can convince
> more people that it can be enabled by default. Here are my thoughts.
> There are two areas of improvements:
>
> 1. scheduling, and
> 2. process handling, i.e., how to have multiple vacuum processes running
> at any time.
>
> I ripped out the part about having multiple "vacuum queues", as it was
> incomplete and it was also getting too complex. We need to discuss how
> to do that, because it's a fundamental part of this proposal; the idea
> is to be able to have several vacuums running at any time, but we need
> to find a way to specify a policy for it.
====8< snip >8====
> So the scheduler, at startup, loads the whole schedule in memory, and
> then wakes up at reasonable intervals and checks whether these equations
> hold for some of the tables it's monitoring. If they do, then launch a
> new worker process to do the job.
>
> We need a mechanism for having the scheduler rescan the schedule when a
> user modifies the catalog -- maybe having a trigger that sends a signal
> to the process is good enough (implementation detail: the signal must be
> routed via the postmaster, since the backend cannot hope to know the
> scheduler's PID. This is easy enough to do.)
While we are talking autovacuum improvements, I'd like to also see some better
logging, something that is akin to the important information of vacuum
verbose being logged to a table or baring that the error_log. I'd like to be
able to see what was done, and how long it took to do for each relation
touched by av. A thought, having this information may even be usefull for
the above thought of scheduler because we may be able to build some sort of
predictive scheduling into this.