Re: No Index-Only Scan on Partial Index

From: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: No Index-Only Scan on Partial Index
Date: 2013-10-03 17:21:22
Message-ID: 12972596-5190-4CAF-8169-2EDF48483E42@justatheory.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Oct 2, 2013, at 5:07 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

> > Hrm. I get a seq scan for that query:
> >
> > create index on try(upper_inf(irange));
> > explain select * from try where upper_inf(irange);
> > QUERY PLAN
> > -----------------------------------------------------------
> > Seq Scan on try (cost=0.00..1887.00 rows=33333 width=68)
> > Filter: upper_inf(irange)
> >
> > True also if I just select the irange. Is the filter the issue, here?
>
> Turn off seq scan...

That rewards me with a bitmap heap scan:

EXPLAIN select * from try where upper_inf(irange);

QUERY PLAN
--------------------------------------------------------------------------------------
Bitmap Heap Scan on try (cost=935.63..2197.63 rows=33333 width=68)
Filter: upper_inf(irange)
-> Bitmap Index Scan on try_upper_inf_idx (cost=0.00..927.30 rows=50000 width=0)
Index Cond: (upper_inf(irange) = true)

But anyway, I still don’t understand why, if the function used to store the value is immutable (as upper_inf() is), why Postgres doesn't do an index scan. Is this something that could be improved in the planner?

Thanks,

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-10-03 17:46:05 Re: record identical operator - Review
Previous Message Steve Singer 2013-10-03 17:03:07 Re: logical changeset generation v6.2