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

From Tom Lane
Subject Re: autovacuum next steps, take 3
Date
Msg-id 23334.1173754744@sss.pgh.pa.us
Whole thread Raw
In response to Re: autovacuum next steps, take 3  (Galy Lee <lee.galy@oss.ntt.co.jp>)
Responses Re: autovacuum next steps, take 3  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
Galy Lee <lee.galy@oss.ntt.co.jp> writes:
> We can use the fix-size share memory to maintain such a queue. The
> maximum task size is the number of all tables. So the size of the queue
> can be the same with max_fsm_relations which is usually larger than the
> numbers of tables and indexes in the cluster.

The trouble with that analogy is that the system can still operate
reasonably sanely when max_fsm_relations is exceeded (at least, the
excess relations behave no worse than they did before we had FSM).
If there are relations that autovacuum ignores indefinitely because they
don't fit in a fixed-size work queue, that will be a big step backward
from prior behavior.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Log levels for checkpoint/bgwriter monitoring
Next
From: Tom Lane
Date:
Subject: Re: Log levels for checkpoint/bgwriter monitoring