Re: btree split logic is fragile in the presence of large index items
От | Peter Eisentraut |
---|---|
Тема | Re: btree split logic is fragile in the presence of large index items |
Дата | |
Msg-id | Pine.LNX.4.21.0007190246000.1545-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | btree split logic is fragile in the presence of large index items (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: btree split logic is fragile in the presence of large index items
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: