Re: autovacuum next steps

I'm wondering if we can do one better...

Since what we really care about is I/O responsiveness for the rest of
the system, could we just time how long I/O calls take to complete? I
know that gettimeofday can have a non-trivial overhead, but do we care
that much about it in the case of autovac?

On Fri, Feb 16, 2007 at 05:37:26PM -0800, Ron Mayer wrote:
> 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.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)