Tom Lane wrote:
Jeff Davis <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
