Re: btree split logic is fragile in the presence of lar ge index items - Mailing list pgsql-hackers

From Tom Lane
Subject Re: btree split logic is fragile in the presence of lar ge index items
Date
Msg-id 22014.964030428@sss.pgh.pa.us
Whole thread Raw
In response to RE: btree split logic is fragile in the presence of lar ge index items  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Responses RE: btree split logic is fragile in the presence of lar ge index items  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-hackers
"Mikheev, Vadim" <vmikheev@SECTORBASE.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


pgsql-hackers by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: RE: btree split logic is fragile in the presence of lar ge index items
Next
From: Mikhail Terekhov
Date:
Subject: Re: Untrusted PL/Tcl?