Re: [HACKERS] Fix up for BTP_CHAIN problems

Wayne Piekarski <wayne@senet.com.au> writes:
> Well, we thought about this, and had a look at every table and index we'd
> ever had BTP_CHAIN problems with, and all had massive duplication of
> values in the particular columns. Ie, one table has 1.5 million rows, and
> one of the columns with an index on it (snum) has only 20000 unique values
> - this particular table was very troublesome, whereas others weren't so
> bad because they were a lot smaller.

That's real useful info --- thanks!  So the BTP_CHAIN problem is getting
caused by some kind of error in btree's handling of equal keys.

> Would a solution to the problem be to automatically include the row OID
> when creating an index?

Vadim had muttered about doing something like that as a substitute for
fixing the equal-keys logic, but it seems like a kluge to me, especially
if it makes the index bigger.  (OTOH I think he was envisioning using
some already-existing field of index tuple headers as the tiebreaker,
so maybe it wouldn't cost any space.)

Vadim, I just committed a change I'd been sitting on for a couple of
months: it eliminates bt_firsteq() by making bt_binsrch()'s binary search
logic deal with equal keys.  It might be worth your time to look it
over.  I did not change the code's behavior, but I think I did improve
the clarity and I certainly added a bunch of documentation.  The old
code had a bunch of strange behavior at boundary conditions, all of
which I replicated and documented, but I can't help wondering whether
it was all correct...
        regards, tom lane