Re: autovacuum next steps - Mailing list pgsql-hackers

From Ron Mayer
Subject Re: autovacuum next steps
Date
Msg-id 45D65C56.2000300@cheapcomplexdevices.com
Whole thread Raw
In response to autovacuum next steps  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: autovacuum next steps  ("Jim C. Nasby" <jim@nasby.net>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: NULL and plpgsql rows
Next
From: Bruce Momjian
Date:
Subject: Re: add to ToDo, please