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 primary key,
which may end up being a very large index as a result
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
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, 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
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
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 check
