Jeff Davis <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster