Re: autovacuum next steps

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.

In response to

Responses

Browse pgsql-hackers by date

  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