Re: Unique constraints for non-btree indexes

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Unique constraints for non-btree indexes
Date: 2006-01-18 21:47:23
Message-ID: 20060118214723.GG27070@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 18, 2006 at 04:18:10PM -0500, Tom Lane wrote:
> I think the generalization that would be appropriate for GIST is that
> a "unique" index guarantees there are no two entries x, y such that
> x ~ y, where ~ is some boolean operator nominated by the opclass. We'd
> probably have to insist that ~ is commutative (x ~ y iff y ~ x).

Commutative, that's the criteria I was looking for. To be senseble for
this purpose, the operator has to be commutative (the commutator is
itself). This works for b-tree by including = and excluding < and >.
Similarly for GiST indexes, contains no, overlaps yes. That's a fairly
easy test.

> Concurrent insertion into a unique GIST index seems a bit nasty. In
> btree we can identify a unique page to lock for any given key value
> to ensure that no one else is concurrently inserting a conflicting
> key, thus usually allowing concurrent insertions of different keys.
> But I don't see how you do that for an arbitrary ~ operator.

Well, the best I could come up with was to just do the insert for value
X and then do a full index scan for X across the given constraint
operator (~). Any matches would need to go through the
check_unique_index function as defined earlier. The only issue is that
we can't really do easy optimisation. In the case of deferred
constraints you can't even remember where in the tree you were because
new keys could be added anywhere so you always have to do from the top.

The issue I get is deadlocks:

1. Process A inserts value X
2. Process B inserts value Y (where X ~ Y is true)
3. Process A begins scan, finds Y and waits for B
4. Process B begins scan, finds X and waits for A

Oops. The only way I can think of solving that is by marking the
entries tentative until the scan is complete and provide a way of
resolving conflicts between two tentative entries. Requires more
thinking.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2006-01-18 21:52:04 Re: No heap lookups on index
Previous Message Martijn van Oosterhout 2006-01-18 21:32:53 Re: Unique constraints for non-btree indexes