Gregory Stark wrote: > "Tom Lane" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org