Re: Index not used with IS NULL

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dmitry Tkach <dmitry(at)openratings(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Index not used with IS NULL
Date: 2003-02-18 01:26:45
Message-ID: 20030218012644.GA23778@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Feb 17, 2003 at 10:52:54AM -0500, Tom Lane wrote:
> Dmitry Tkach <dmitry(at)openratings(dot)com> writes:
> > Tom Lane wrote:
> >> I don't see anything dangerous about it --- except perhaps to
> >> readability and mantainability of the code. The problem is that IS NULL
> >> doesn't fit into the operator-and-opclass model of what indexes can do.
> >> If you can find a solution to that problem that's not a complete kluge,
> >> I'm all ears.
>
> > Well... At first glance, it seems that what needs to be done is:
>
> > - add a special case in is_indexable_operator() to return true for IS_NULL
>
> And is_indexable_operator() will know that this is safe how? Or do you
> plan to fix the other three index types to support NULLs too?

I would have thought that the other index type supported null anyway, for
the purposes of uniqueness checks.

> > - modify _bt_checkkeys () to return isNull from inside if
> > (key->sk_flags & SK_ISNULL) clause instead of just false.
> > - remove sk_flags & SK_ISNULL checks from _bt_orderkeys
>
> IIRC, SK_ISNULL marks that the value being compared against is null
> --- not that the scan operator is ISNULL. An approach as above would
> cause "WHERE x = something" indexscans to start returning nulls if the
> "something" is null, no? You need a representation that preserves the
> difference between "x = NULL" and "x IS NULL". The ScanKey structure
> can't do this at the moment, mainly because it assumes that the scan
> operator *is* an operator. Which IS NULL is not.

I remember looking into this a while ago. My solution to that problem was
that x = NULL is always NULL and so doesn't need to go through the scan
anyway (index or sequential). Once you've taken care of the x = NULL case
elsewhere, you can use the available state for x IS NULL.

I don't remember if I actually found the place to fix that though.

I would really like it if this was finally made to work.
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Support bacteria! They're the only culture some people have.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-02-18 01:30:32 Re: TIMESTAMP WITH( OUT)? TIME ZONE indexing/type choice...
Previous Message Greg Stark 2003-02-18 00:43:27 Re: TIMESTAMP WITH( OUT)? TIME ZONE indexing/type choice...