On Mon, Mar 14, 2016 at 8:43 PM, Peter Geoghegan <p...@heroku.com> wrote: > * I think the comparison logic may have a bug. > > Does this work with amcheck? Maybe it works with bt_index_check(), but > not bt_index_parent_check()? I think that you need to make sure that > _bt_compare() knows about this, too. That's because it isn't good > enough to let a truncated internal IndexTuple compare equal to a > scankey when non-truncated attributes are equal. I think you need to > have an imaginary "minus infinity" attribute past the first > non-truncated attribute (i.e. "minus infinity value" for the first > *truncated* attribute). That way, the downlinks will always be lower > bounds when the non-"included"/truncated attributes are involved. This > seems necessary. No?
Oh, BTW: You probably need to worry about high key items as a special case, too. Note that there is a special case when the ScanKey is equal to the high key on a page during insertion. As the nbtree README puts it: """ An insertion that sees the high key of its target page is equal to the key to be inserted has a choice whether or not to move right, since the new key could go on either page. (Currently, we try to find a page where there is room for the new key without a split.) """ Just something to watch out for if you add "minus infinity" attributes as I suggested. Not exactly sure what to do about this other problem, but it seems manageable. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers