RE: btree split logic is fragile in the presence of lar ge index items

> > While implementing multi-key btree-s for 6.1 I found problems with
> > duplicates handling and this is why extra logic was added. 
> > But I never was happy with this logic -:)
> 
> Do you not like the proposal I was suggesting?  I thought it 
> was pretty much what you said yourself a few months ago...

Do not add TID to key but store key anywhere in duplicate chain and
just read lefter child page while positioning index scan, as we do
right now for partial keys?

This will result in additional reads but I like it much more than
current "logic"... especially keeping in mind that we'll have to
implement redo/undo for btree very soon and this would be nice
to simplify things -:) But if you're going to change btree then
please do it asap - I hope to begin btree redo/undo implementation
in 2-3 days, just after heap...

Vadim