| 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: | Whole Thread | Raw Message | 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 |