Re: RFC: changing autovacuum_naptime semantics

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RFC: changing autovacuum_naptime semantics
Дата
Msg-id 21674.1173418961@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: RFC: changing autovacuum_naptime semantics  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: RFC: changing autovacuum_naptime semantics  (Galy Lee <lee.galy@oss.ntt.co.jp>)
Re: RFC: changing autovacuum_naptime semantics  (Grzegorz Jaskiewicz <gj@pointblue.com.pl>)
Re: RFC: changing autovacuum_naptime semantics  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Now regarding your restartable vacuum work.  I think that stopping a
> vacuum at some point and being able to restart it later is very cool and
> may get you some hot chicks, but I'm not sure it's really useful.

Too true :-(

> I think it makes more sense to do something like throttling an ongoing
> vacuum to a reduced IO rate, if the maintenance window closes.  So if
> you're in the middle of a heap scan and the maintenance window closes,
> you immediately stop the scan and go the the index cleanup phase, *at a
> reduced IO rate*.

Er, why not just finish out the scan at the reduced I/O rate?  Any sort
of "abort" behavior is going to create net inefficiency, eg doing an
index scan to remove only a few tuples.  ISTM that the vacuum ought to
just continue along its existing path at a slower I/O rate.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

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