From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Performance-improvement idea: shortcircuit unique-index checks |
Date: | 2001-02-19 21:48:00 |
Message-ID: | Pine.BSF.4.21.0102191338230.84481-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-02-19 21:52:46 | Re: Performance-improvement idea: shortcircuit unique-index checks |
Previous Message | Larry Rosenman | 2001-02-19 21:44:50 | Re: PHP 4.0.4pl1 / Beta 5 |