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
Re: RFC: changing autovacuum_naptime semantics Re: RFC: changing autovacuum_naptime semantics |
Список | 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 по дате отправления: