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 [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
