Re: Bitmap index scans use of filters on available columns

On 4 November 2015 at 16:59, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On 4 November 2015 at 16:14, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> You're missing my point: that is possible in an indexscan, but *not* in
> a
> >> bitmap indexscan, because the index AM APIs are totally different in the
> >> two cases. In a bitmap scan, nothing more than a TID bitmap is ever
> >> returned out to anyplace that could execute arbitrary expressions.
>
> > Still misunderstanding each other... sorry about that
>
> > If a btree can Filter y like that on an IndexScan, then it can also apply
> > that Filter on y when it is looking through rows before it adds them to
> the
> > bitmap.
>
> btree applies no such filter in either case. "Filter" conditions are
> applied outside the index AM --- and yes, I will resist any proposal to
> relocate that responsibility.
>

I don't think anyone has argued that point, yet, we just don't have enough
info to agree yet.

As Jeff said in his OP, "Is there a fundamental reason the filter on y is
not being applied to
the index scan, rather than the heap scan?", which still stands.

Why would you resist? And/Or Why is that important?

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services