Re: WIP: generalized index constraints - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: generalized index constraints
Date
Msg-id 20732.1246993029@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: generalized index constraints  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: WIP: generalized index constraints  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Tue, 2009-07-07 at 18:36 +0100, Simon Riggs wrote:
>> On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
>> It is likely to be useful in the future to allow an index with N
>> columns, yet which can provide uniqueness with < N of those columns.
>> This capability is known as covered indexes and will be important if
>> Heikki writes his index-only scan code.

> My patch offers this capability, and the language I suggested would
> support it.

> In the current version of the patch, just use InvalidStrategy (0)
> instead of, say, BTEqualStrategyNumber (3) for the attributes that you
> don't want to be a part of the constraint. Some of the proper error
> checking is not done yet, but it will work.

I don't think this even approximates the need --- in particular it's not
clear what the semantics of combination across different index columns
are.  I assume you've hot-wired it so that several BTEqualStrategyNumber
columns will work like a normal multicolumn uniqueness constraint (IOW
it's okay as long as at least one column is NULL or isn't equal).  But
I'm not at all sure that's what I'd want for some other operator type.

Also, what happens if you want to use the same index to support more
than one logical constraint?  This is impossible if you put the
information into pg_index, I think.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Maintenance Policy?
Next
From: Heikki Linnakangas
Date:
Subject: Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby