Re: Performance-improvement idea: shortcircuit unique-index checks

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.

In response to

Browse pgsql-hackers by date

  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