From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tobias Brox <tobias(at)nordicbet(dot)com> |
Cc: | Bruno Wolff III <bruno(at)wolff(dot)to>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Index on a NULL-value |
Date: | 2005-05-31 04:21:25 |
Message-ID: | 87mzqcvxdm.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tobias Brox <tobias(at)nordicbet(dot)com> writes:
> [Bruno Wolff III - Mon at 10:36:33PM -0500]
> > You want something like this:
> > CREATE INDEX b_is_null ON mock(b) WHERE b IS NULL;
>
> Oh, cool. I wasn't aware that this is possible. This would probably help
> us a lot of places. :-)
Yeah it's a cool feature.
I'm not 100% sure but I think it still won't consider this index unless the
column being indexed is used in some indexable operation. So for example if
you had
CREATE INDEX b_null on mock(other) WHERE b IS NULL;
and something like
SELECT * FROM b WHERE b IS NULL ORDER BY other
or
SELECT * FROM b where other > 0 AND b IS NULL
then it would be a candidate because the ORDER BY or the other > 0 make the
index look relevant. But I don't think (again I'm not 100% sure) that the
partial index WHERE clause is considered in picking which indexes to consider.
It *is* considered in evaluating which index is the best one to use and
whether it's better than a sequential scan. Just not in the initial choice of
which indexes to look at at all.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-31 05:12:46 | Re: Index on a NULL-value |
Previous Message | Tom Lane | 2005-05-31 04:18:33 | Re: Index on a NULL-value |