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