Jeff Davis <pgsql@j-davis.com> writes:
> * For a large table, do lazy_scan_heap, scan_heap, and a sequential
> scan usually progress at approximately the same rate?
scan_heap would probably be faster than a regular seqscan, since it
isn't doing any where-clause-checking or data output. Except if you've
got vacuum-cost-limit enabled, which I think is likely to be true by
default in future. Another problem is that lazy_scan_heap stops every
so often to make a pass over the table's indexes, which'd certainly
cause it to fall out of sync with more typical seqscans.
The vacuum-cost-limit issue may be sufficient reason to kill this idea;
not sure.
> * Just adding in the syncscan to scan_heap and lazy_scan_heap seems
> very easy at first thought. Are there any complications that I'm
> missing?
I believe there are assumptions buried in both full and lazy vacuum that
blocks are scanned in increasing order. Not sure how hard that would be
to fix or work around. The only one I can specifically recall in lazy
vacuum is that we assume the list of deletable TIDs is sorted a priori.
Possibly you could deal with that by forcing an index-vacuum pass at the
instant where the scan would wrap around, so that the list could be
cleared before putting any lower-numbered blocks into it.
regards, tom lane
