Re: Performance-improvement idea: shortcircuit unique-index checks - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: Performance-improvement idea: shortcircuit unique-index checks
Date
Msg-id Pine.BSF.4.21.0102191338230.84481-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Performance-improvement idea: shortcircuit unique-index checks  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: PHP 4.0.4pl1 / Beta 5
Next
From: Bruce Momjian
Date:
Subject: Re: Performance-improvement idea: shortcircuit unique-index checks