From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Subject: | Re: autovacuum next steps |
Date: | 2007-02-17 01:37:26 |
Message-ID: | 45D65C56.2000300@cheapcomplexdevices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Mayer | 2007-02-17 01:44:40 | Re: Priorities for users or queries? |
Previous Message | Bruce Momjian | 2007-02-17 01:35:56 | Re: NULL and plpgsql rows |