Re: RFC: changing autovacuum_naptime semantics - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: RFC: changing autovacuum_naptime semantics
Date
Msg-id 20070309124859.GC4588@alvh.no-ip.org
Whole thread Raw
In response to Re: RFC: changing autovacuum_naptime semantics  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> 
> > Er, why not just finish out the scan at the reduced I/O rate?  Any sort
> > of "abort" behavior is going to create net inefficiency, eg doing an
> > index scan to remove only a few tuples.  ISTM that the vacuum ought to
> > just continue along its existing path at a slower I/O rate.
> 
> I think the main motivation to abort a vacuum scan is so we can switch to some
> more urgent scan. So if in the middle of a 1-hour long vacuum of some big
> warehouse table we realize that a small hot table is long overdue for a vacuum
> we want to be able to remove the tuples we've found so far, switch to the hot
> table, and when we don't have more urgent tables to vacuum resume the large
> warehouse table vacuum.

Why not just let another autovac worker do the hot table?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: CLUSTER and MVCC
Next
From: Csaba Nagy
Date:
Subject: Re: CLUSTER and MVCC