Re: Performance-improvement idea: shortcircuit unique-index checks
От | Stephan Szabo |
---|---|
Тема | Re: Performance-improvement idea: shortcircuit unique-index checks |
Дата | |
Msg-id | Pine.BSF.4.21.0102191338230.84481-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Performance-improvement idea: shortcircuit unique-index checks (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, 19 Feb 2001, Tom Lane wrote: > I'm not quite sure how to implement this, but I wanted to toss the idea > out for discussion. Probably we'd have to have some cooperation between > the heap_update level (where the fact that it's an update is known, and > where we'd have a chance to test for changes in particular columns) and > the index access level. Maybe it's wrong for the index access level to > have primary responsibility for uniqueness checks in the first place. > > Obviously this isn't going to happen for 7.1, but it might make a nice > performance improvement for 7.2. > > Comments? This sounds like a win for alot of updates where keys don't change. Also, if work is going to be done here, it might be nice to make the unique constraint have the correct semantics for checking after statement rather than per-row when multiple rows are changed in the same statement since I'm pretty sure the standard semantics is that as long as the rows are different at the end of the statement it's okay (which is not what we do currently AFAICS). I'm really not sure what's involved in that though.
В списке pgsql-hackers по дате отправления: