| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Subject: | Re: Bitmap index scans use of filters on available columns |
| Date: | 2015-11-04 15:59:53 |
| Message-ID: | 3200.1446652793@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2015-11-04 16:02:33 | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
| Previous Message | Simon Riggs | 2015-11-04 15:50:21 | Re: Bitmap index scans use of filters on available columns |