Manfred Koizar <mkoi-pg@aon.at> writes:
> On leaf pages order index tuples by heap item pointer, if otherwise
> equal. In IndexScanDescData remember the whole index tuple (including
> the heap item pointer) instead of ItemPointerData. Then depending on
> scan direction _bt_next() would look for the first index tuple greater
> or less than currentItem respectively.
Doesn't help, I fear. Finding your place again is only one part
of the problem. The other part is being sure that VACUUM won't delete
the heap tuple before you get to it. The interlock at the index stage
is partly a proxy to protect heap tuples that are about to be visited
by indexscans (ie, indexscan has read an index tuple but hasn't yet
acquired pin on the referenced heap page).
> (+) btinsert knows, where to insert a new tuple, even if there are
> lots of duplicates (no random())
This is not a (+) but a (-), I think. Given the current CVS tip
behavior it is better for a new tuple to be inserted at the front of
the series of matching keys --- in unique indexes this allows repeated
updates without degrading search time. We are not currently exploiting
that as much as we should --- I suspect btree insertion should be more
willing to split pages than it now is.
regards, tom lane
