I've committed a rewritten version of this patch. Heikki Linnakangas <[EMAIL PROTECTED]> writes: > On Fri, 5 May 2006, Tom Lane wrote: >> btbulkdelete arrives at a page, it need take no special action unless the >> page is newly split *and* its right-link points to a lower physical >> address. If that's true, then after vacuuming the page, follow its >> right-link and vacuum that page; repeat until arriving at a page that is >> either not newly split or is above the current location of the outer loop. >> Then return to the outer, sequential-scan loop.
> It'd be a bit more efficient to finish the sequential-scan first, and > memorize the newly-split pages' right-links as they're encountered. Then > scan those pages as a separate second pass, or earlier if we run out of > memory reserved for memorizing them. I didn't do this. Aside from the extra memory requirement, it's not apparent to me that it'd make things faster. The disadvantage is that it would require more page reads than the other way: if you visit the split page immediately, and note that its right-link is above the current outer loop location, then you can skip following the right-link because you know you'll visit the page later. If you postpone then you have to chase every chain until actually reading a page with an old cycle ID. I think this extra I/O would likely outweigh any savings from not interrupting the main scan. > If btbulkdelete always clears the marker (assuming zero isn't a valid > value), 16 bits is plenty. Unless a vacuum is aborted, there should never > be a value older than current value - 1 in the index. We could live with a > 2-bit counter. For the moment, the code is only clearing the marker if it's equal to the current cycle ID. This is sufficient to recognize definitely-already-processed pages, but it doesn't prevent false positives in general. If we ever need the space we could narrow the counter, at the cost of having to expend more I/O to keep the values cleared. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match