db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Unique constraints and null
Date Thu, 23 Mar 2006 19:13:10 GMT
I agree that these 2 approaches should not affect performance of the
index.  I only bring it up as I once looked at a third option which
put all the work in the index, which involved sometimes treating
the nulls as different and sometimes the same - as you can imagine
it added some ugly special case code.  I gave up on the approach as
I saw what it did to a lot of the basic current assumptions, and would
affect throughput of the normal path through the code.

Bernt M. Johnsen wrote:
>>>>>>>>>>>>>Mike Matrigali wrote (2006-03-22 11:22:39):
>>I am not aware of any work being done.  My only concern is that such an 
>>implementation does not the affect the performance of existing index 
>>operations.  I would be interested in knowing what approach you are 
>>considering to address it.
> Some thoughts: Basically I can see two approaches
> 1) Ignore null values in the index. Should be straight forward in the
> optimizer to know when to use the index or not. Downside: When there
> are multiple columns in the index, there are more cases when the index
> is unisable.
> 2) Put the nulls into the index. We would then have to consider nulls
> unequal to nulls when checking the constraint, but keep null equal to
> null when inserting into the B-trees.
> I can't see any reason (except bugs, of course) that a proper
> implementation should affect performance for existing index
> functionality.

View raw message