Re: (partial?) indexes, LIKE and NULL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marinos J(dot) Yannikos" <mjy(at)geizhals(dot)at>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: (partial?) indexes, LIKE and NULL
Date: 2004-01-27 22:46:38
Message-ID: 29758.1075243598@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Marinos J. Yannikos" <mjy(at)geizhals(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Joe Conway 2004-01-28 00:56:18 Re: pl/pgSQL versus pl/Python
Previous Message Josh Berkus 2004-01-27 20:07:33 Re: On the performance of views