Re: Use of additional index columns in rows filtering

On Tue, Aug 8, 2023 at 11:36 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> Assuming that that happens, then it immediately gives index scans a
> huge advantage over bitmap index scans. At that point it seems
> important to describe (in high level terms) where it is that the
> advantage is innate, and where it's just because we haven't done the
> required work for bitmap index scans. I became confused on this point
> myself yesterday. Admittedly I should have been able to figure it out
> on my own -- but it is confusing.

I also have some doubts about the costing. That contributed to my confusion.

Take my " four = 1 and two != 1" example query, from earlier today. As
I said, that gets a bitmap index scan, which does a hugely excessive
amount of heap access. But once I force the planner to use an index
scan, then (as predicted) there are useful index filters -- filters
that can eliminate 100% of all heap accesses. Yet the planner still
thinks that the total cost of the bitmap scan plan is only 415.28,
versus 714.89 for the index scan plan. Perhaps that's just because
this is a tricky case, for whatever reason...but it's not obvious what
that reason really is.

You keep pointing out that your patch only makes isolated, local
changes to certain specific plans. While that is true, it's also true
that there will be fairly far removed consequences. Why shouldn't I
treat those things as in scope?

--
Peter Geoghegan