On 4 November 2015 at 16:59, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > On 4 November 2015 at 16:14, Tom Lane <t...@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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
