Thread: (partial?) indexes, LIKE and NULL

Hi,

with the following table:

     Table "public.foo"
  Column | Type | Modifiers
--------+------+-----------
  t      | text |
Indexes:
      "a" btree (t)

Shouldn't queries that use
    ... where t like '%something%'

benefit from "a" when t is NULL in almost all cases, since the query
planner could use "a" to access the few non-NULL rows quickly? It
doesn't seem to work right now.

(I assume that it would make no difference if the index "a" was partial,
excluding NULLs)

Regards,
-mjy

My understanding is that having NULL values in an index breaks it completely.  Meaning it won't be used in any query
planning. Maybe I'm wrong though... 


-----Original Message-----
From:    Marinos J. Yannikos [mailto:mjy@geizhals.at]
Sent:    Tue 1/27/2004 12:26 PM
To:    pgsql-performance@postgresql.org
Cc:
Subject:    [PERFORM] (partial?) indexes, LIKE and NULL

Hi,

with the following table:

     Table "public.foo"
  Column | Type | Modifiers
--------+------+-----------
  t      | text |
Indexes:
      "a" btree (t)

Shouldn't queries that use
    ... where t like '%something%'

benefit from "a" when t is NULL in almost all cases, since the query
planner could use "a" to access the few non-NULL rows quickly? It
doesn't seem to work right now.

(I assume that it would make no difference if the index "a" was partial,
excluding NULLs)

Regards,
-mjy


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

"Marinos J. Yannikos" <mjy@geizhals.at> writes:
> Shouldn't queries that use
>     ... where t like '%something%'
> benefit from [an index on t] when t is NULL in almost all cases, since
> the query planner could use [it] to access the few non-NULL rows
> quickly?

No, and the reason is that the planner *can't* use the index that way.
To do that we'd have to support "x IS NOT NULL" as an indexable
operator, which we don't.  This is exactly the same stumbling block as
for more-direct uses of indexes to search for NULL or NOT NULL rows.
See the pghackers archives for more details.

> (I assume that it would make no difference if the index "a" was partial,
> excluding NULLs)

You could do

    create index a on foo(t) where t is not null;

and then this index would likely get used for any query explicitly
mentioning "AND t is not null".  The planner will not induce such a
where clause entry from the presence of other tests on t, however.

            regards, tom lane