"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. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(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
