Re: Bitmap index scans use of filters on available columns - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Bitmap index scans use of filters on available columns
Date
Msg-id CANP8+j++8-yxw9F7fbqjrAkJP2KN5HEgxYAebxZOUge68N2tpQ@mail.gmail.com
Whole thread Raw
In response to Re: Bitmap index scans use of filters on available columns  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 4 November 2015 at 16:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Simon Riggs <simon@2ndquadrant.com> writes:
> On 4 November 2015 at 16:14, Tom Lane <tgl@sss.pgh.pa.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/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Next
From: Tom Lane
Date:
Subject: Re: patch for geqo tweaks