"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
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
pgsql-performance by date
|Next:||From: Joe Conway||Date: 2004-01-28 00:56:18|
|Subject: Re: pl/pgSQL versus pl/Python|
|Previous:||From: Josh Berkus||Date: 2004-01-27 20:07:33|
|Subject: Re: On the performance of views|