Re: 9.5alpha1: Partial index not used

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: 9.5alpha1: Partial index not used
Date: 2015-08-01 00:03:41
Message-ID: 13924.1438387421@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Peter J. Holzer" <hjp-pgsql(at)hjp(dot)at> writes:
> Consider this table:
> ...
> "concept_start_idx" btree (start) WHERE start IS NOT NULL

> and this query:

> select id as IdValue, canonicalname as Description, null as IsLeaf from public.concept where start;

> Clearly this should be able to use the partial index (if start is true
> it is also not null)

As you surmise, there's no proof rule for that.

> and since there are only 3 out of 3 million rows in
> result it would also be beneficial (and PostgreSQL 9.1 did use the
> index).

... and there wasn't in 9.1 either. I get a seqscan from examples like
this in every branch back to 8.3, which is as far back as I can test
conveniently.

This is the exact test case I'm using:

create table foo as select null::bool as start, generate_series(1,100000) as x;
update foo set start = true where x < 10;
create index foos on foo (start) where start is not null;
analyze foo;
explain select * from foo where start;
explain select * from foo where start = true;
explain select * from foo where start is not null;

Only the last case produces use of the index. I agree that it'd be better
if they all did, but I'm disinclined to consider it a bug fix unless you
can show a specific case in which there's a performance regression from
older releases.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2015-08-01 04:11:55 Re: BUG #13530: sort receives "unexpected out-of-memory situation during sort"
Previous Message brent_despain 2015-07-31 22:06:18 BUG #13530: sort receives "unexpected out-of-memory situation during sort"