Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
>> * 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.
In this case, we're still scanning the table in increasing order, the
zero-point is just shifted. We can still do a binary search if we do it
in a whacky module-arithmetic fashion.
I believe TID list ordering is the only reason why we need to scan in order.
I don't think sync-scanning vacuum is worth pursuing, though, because of
the other issues: index scans, vacuum cost accounting, and the fact that
the 2nd pass would be harder to synchronize. There's a lot of other
interesting ideas for vacuum that are more generally applicable.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
