tom lane wrote: > How does that help? The left-moving indexscan still has no > way to recover. It can't go back to the page it was on > before and try to determine which entries you added there, > because it has no reliable reference point to do so. The > entry it previously returned might not be there anymore, and > in a non-unique index key comparisons won't help. And even > more to the point, how would it know you've changed the left > page? It has no idea what the previous "page version" on the > left page was, because it was never there before.
Another way this could be handled is by not merging onto one of the existing pages but to a brand new page, a kind of special case shadow index page. That way the sibling pointers, and leaf page pointer in the parent could all be updated atomically to point to the new page. In-process index scans would still reference the merged pages which would not be deleted but marked as dead using a mechanism like you proposed for marking empty pages dead with the next-transaction-ID counter. Merging could be done after a VACUUM pass that performs deletion of empty pages in order to provide a pool of empty pages to use for the merge. This would keep the index from temporarily growing during the merge process. A similar approach could be used to reorder the index pages in the background. An index that was reordered to fairly closely reflect the tree as a breadth first traversal would provide much faster index scans if the file is not heavily fragmented. - Curtis ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
