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

"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> writes:
>> 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"...

Offhand it seems good to me too. For the normal case where there are
many keys per page and not so many duplicates, an unneeded read should
be rare anyway.

I will need to study Lehman & Yao a little more to ensure they don't
have a problem with it, but if not I'll do it that way. (I was
surprised to realize that Lehman is the same Phil Lehman I knew in
grad school ... in fact he was probably working on this paper when
I knew him. Small world ain't it.)

> 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...

Slavedriver ;-) ... I'll see what I can do ...

regards, tom lane