Re: RFC: changing autovacuum_naptime semantics

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