Re: autovacuum next steps, take 3 - Mailing list pgsql-hackers

From Galy Lee
Subject Re: autovacuum next steps, take 3
Date
Msg-id 45F5389B.9020102@oss.ntt.co.jp
Whole thread Raw
In response to autovacuum next steps, take 3  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: autovacuum next steps, take 3  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: autovacuum next steps, take 3  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera wrote:
>worker to-do list
>-----------------
>It removes from its to-do list the tables being processed.  Finally, it
>writes the list to disk.

I am worrying about the worker-to-do-list in your proposal. I think
worker isn't suitable to maintain any vacuum task list; instead
it is better to maintain a unified vacuum task queue on autovacuum share
memory.

Here are the basic ideas:

* Why is such a task queue needed?

- Launcher might schedule all vacuum tasks by such a queue. It provides
a facility to schedule tasks smartly for further autovacuum improvement.

- Also such a task list can be viewed easily from a system view. This
can be implemented easily in 8.3 by the task queue.

* VACUUM task queue

VACUUM tasks of cluster are maintained in a unified cluster-wide queue
in the share memory of autovacuum.
 global shared TaskInfo tasks[];

It can be viewed as:

SELECT * FROM pg_autovacuum_tasks; dbid | relid | group | worker
-------+-------+-------+--------20000 | 20001 |     0 |  100120000 | 20002 |     0 |30000 | 30001 |     0 |  1002

VACUUM tasks belong to the same database might be divided into several
groups. One worker might be assigned to process one specific task group.

The task queue might be filled by dedicated task-gathering-worker or it
might be filled by *external task gatherer*.

It allows external program to develop a more sophisticated vacuum
scheme. Based on previous discussion, it appears that it is difficult to
implement an all-purpose algorithm to satisfy the requirements of all
applications. It is better to allow user to develop their vacuum
strategies. *User-defined external program* might fill the task queue,
and schedule tasks by their own strategy. Launcher will response for
coordinating workers only. This pluggable-vacuum-strategy approach seems
a good solution.

* status of worker

It is also convenience to allow user to monitor the status of vacuum
worker by a system view.The snapshot of worker can also be viewed as:

SELECT * FROM pg_autovacuum_workers;pid  |  dbid | relid | group
------+-------+-------+-------1001 | 20000 | 20001 |     01002 | 30000 | 30001 |     0


Best Regards
Galy Lee
lee.galy _at_ oss.ntt.co.jp
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Bug: Buffer cache is not scan resistant
Next
From: Heikki Linnakangas
Date:
Subject: Re: Grouped Index Tuples / Clustered Indexes