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

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?


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden