From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Indexing null dates |
Date: | 2004-04-20 03:33:47 |
Message-ID: | 87ekqj5nms.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Yes, nifty. CREATE INDEX docs updated with:
>
> + <literal>NULL</> values are not indexed by default. The best way
> + to index <literal>NULL</> values is to create a partial index using
> + an <literal>IS NULL</> comparison. <literal>IS NULL</> is more
> + of a function call than a value comparison, and this is why a partial
> + index works.
Uh, this is wrong.
NULLs are indexed. It's just that IS NULL cannot take advantage of it due to
technical details. These are NOT the same thing.
Saying "NULLs are not indexed" will confuse people because it will make them
think that they're not present in the index at all which is what Oracle does.
That has real consequences on queries. The most obvious being that
SELECT * FROM foo ORDER BY bar
cannot take advantage of an index on bar. Oracle programmers are accustomed to
having to had a "WHERE bar IS NOT NULL" or else live with the full table scan
and sort.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-20 03:59:53 | Re: Indexing null dates |
Previous Message | Andreas | 2004-04-20 03:24:54 | Re: plan-reading extensive tutorial? |