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.
