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

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> A more radical way out is to do what Vadim's been saying we should do
>> eventually: redo the btree logic so that there are never "equal" keys
>> (ie, use the item TID as a tiebreaker when ordering items). That would
>> fix our performance problems with many equal keys as well as simplify
>> the code. But it'd be a good deal of work, I fear.

> I wonder, if we are ever to support deferrable unique constraints (or even
> properly working unique constraints, re update t1 set x = x + 1), wouldn't
> the whole unique business have to disappear from the indexes anyway and be
> handled more in the trigger area?

Could be, but I don't think it's relevant to this particular issue.

regards, tom lane