Re: autovacuum next steps, take 3

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: autovacuum next steps, take 3
Дата
Msg-id 23334.1173754744@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: autovacuum next steps, take 3  (Galy Lee <lee.galy@oss.ntt.co.jp>)
Ответы Re: autovacuum next steps, take 3  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: Log levels for checkpoint/bgwriter monitoring
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Log levels for checkpoint/bgwriter monitoring