Re: RFC: changing autovacuum_naptime semantics

Gregory Stark wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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