Re: autovacuum next steps

Поиск
Список
Период
Сортировка
От Ron Mayer
Тема Re: autovacuum next steps
Дата
Msg-id 45D65C56.2000300@cheapcomplexdevices.com
обсуждение исходный текст
Ответ на autovacuum next steps  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: autovacuum next steps  ("Jim C. Nasby" <jim@nasby.net>)
Список pgsql-hackers
Alvaro Herrera wrote:
> 
> Once autovacuum_naptime... autovacuum_max_workers...
> How does this sound?

The knobs exposed on autovacuum feel kinda tangential to
what I think I'd really want to control.

IMHO "vacuum_mbytes_per_second" would be quite a bit more
intuitive than cost_delay, naptime, etc.


ISTM I can relatively easily estimate and/or spec out how
much "extra" I/O bandwidth I have per device for vacuum;
and would pretty much want vacuum to be constantly
running on whichever table that needs it the most so
long as it can stay under that bandwith limit.

Could vacuum have a tunable that says "X MBytes/second"
(perhaps per device) and have it measure how much I/O
it's actually doing and try to stay under that limit?

For more fine-grained control a cron job could go
around setting different MBytes/second limits during
peak times vs idle times.


If people are concerned about CPU intensive vacuums
instead of I/O intensive ones (does anyone experience
that? - another tuneable "vacuum_percent_of_cpu" would
be more straightforward than delay_cost, cost_page_hit,
etc.   But I'd be a bit surprised if cpu intensive
vacuums are common.


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: NULL and plpgsql rows
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: add to ToDo, please