"Simon Riggs" <[EMAIL PROTECTED]> writes:
> If the uniqueness check used a scan key that consisted of all of the
> Primary Key columns, rather than just the index columns then it would be
> able to scan through non-unique index entries to check uniqueness.
> Interestingly, the current uniqueness c
On Thu, 2008-03-20 at 17:38 +, Gregory Stark wrote:
> I don't immediately see any problems aside from reduced concurrency
Agreed. The index would need to be nearly unique in most cases to make
it sensible. But that's a common situation in complex data models.
--
Simon Riggs
2ndQuadrant
On Thu, 2008-03-20 at 18:37 +0100, Martijn van Oosterhout wrote:
> On Thu, Mar 20, 2008 at 02:35:38PM +, Simon Riggs wrote:
> > This would then allow us to use a Hash Index or other index as the basis
> > for a Unique Constraint and/or considerably reduce size of indexes.
>
> I was under the i
On Thu, Mar 20, 2008 at 02:35:38PM +, Simon Riggs wrote:
> The current Unique constraint relies directly upon a Unique index to
> test for uniqueness.
>
> This has two disadvantages:
>
> * only B-Trees currently support Uniqueness
> * We need to create an index on *all* of the columns of the
On Thu, Mar 20, 2008 at 02:35:38PM +, Simon Riggs wrote:
> This would then allow us to use a Hash Index or other index as the basis
> for a Unique Constraint and/or considerably reduce size of indexes.
I was under the impression that the reason only b-tree supported unique
indexes was because
