Satoshi Nagayasu <nagayasus@nttdata.co.jp> writes:
> Attached patch extends vacuum syntax and lazy_scan_heap() function.
> Backend can process the partial vacuum command as below:
> psql$ vacuum table1 (0, 100);
> In the above command, "0" means start block number,
> and "100" means end block number of the vacuum scan.
I think the major problem with this is the (untenable) assumption that
the user is keeping track of the table size accurately. It'd be very
likely that portions of the table get missed if someone tries to
maintain a table using only partial vacuums specified in this way.
I thought about specifying the range using percentages instead of raw
block numbers, but that's got equally bad problems of its own. (If
the table size changes, then successive vacuums from 0-10 and 10-20%
could miss a few blocks in between.)
More generally, any sort of partial vacuum operation is going to be
inherently inefficient because of excessive index scanning --- if
you chop the table into tenths, say, you are probably doing five or
so extra index scans to complete the operation, because of scans forced
with only partially full vacuum memory. Unless you want to redesign
the way index cleanup is done, you won't be able to use this feature
with a scan size small enough that it really makes a meaningful
reduction in the system load produced by a vacuum.
Have you looked at the vacuum cost delay features present in 8.0?
On the whole that seems like a better solution for reducing the impact
of routine vacuuming than trying to manage partial vacuuming with an
approach like this.
regards, tom lane
