Re: Proposal: GiST constraints - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Proposal: GiST constraints
Date
Msg-id 1213033969.24243.20.camel@dogma.ljc.laika.com
Whole thread Raw
In response to Re: Proposal: GiST constraints  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal: GiST constraints  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2008-06-09 at 13:28 -0400, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> > I would like to consider adding constraints to GiST indexes. I think it
> > is possible to add constraints that are more sophisticated than just
> > UNIQUE. My use case is a non-overlapping constraint, but I think it's
> > possible for this to be more general.
> 
> I would like to see something that replaces the current btree-only kluge
> for UNIQUE, if we're going to try to do something "general".  IOW, don't
> think of this as GiST-specific.
> 

I was concerned that the BTree kludge would outperform what I am
suggesting for the case of UNIQUE, and might therefore still be
necessary. 

My proposal requires an extra index lookup, because in GiST a
conflicting tuple isn't necessarily found near the place it might be
inserted. Maybe that cost is not too high, because for the case of BTree
UNIQUE it would just be accessing the same pages twice (once to test for
conflicts, and once to insert). 

I'm not sure exactly what you have in mind when you say "kludge". My
proposal doesn't solve the problem of "update foo set a = a + 1", in
which the UNIQUE constraint may fail when it should succeed. I don't see
how that problem can be solved without deferring the constraint checking
until the end of the statement, which sounds costly.

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: pg_dump restore time and Foreign Keys
Next
From: Joe Conway
Date:
Subject: Re: proposal: new contrib module - session variables