Re: autovacuum next steps, take 3

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> In any case, I still haven't seen a good case made why a global work
> queue will provide better behavior than each worker keeping a local
> queue. The need for small "hot" tables to be visited more often than
> big tables suggests to me that a global queue will actually be
> counterproductive, because you'll have to contort the algorithm in
> some hard-to-understand way to get it to do that.

If we have some external vacuum schedulers, we need to see and touch the
content of work queue. That's why he suggested the shared work queue.
I think the present strategy of autovacuum is not enough in some heavily-used
cases and need more sophisticated schedulers, even if the optimization
for hot tables is added. Also, the best strategies of vacuum are highly
depending on systems, so that I don't think we can supply one monolithic
strategy that fits all purposes.

That was a proposal of the infrastructure for interaction between autovacuum
and user-land vacuum schedulers. Of cource, we can supply a simple scheduler
for not-so-high-load systems, but I need a kind of autovacuum that can be
controlled from an external program that knows user application well.

Though we can use a completely separated autovacuum daemon like as
contrib/pg_autovacuum of 8.0, but I think it is good for us to share
some of the codes between a built-in scheduler and external ones.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center