Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru> writes:
> With planner, the changes are more complex. Two things must be done
> there. First, when the tlist is empty, we must use a different cost
> function for bitmap heap scan, because the heap access pattern is
> different. Second, choose_bitmap_and() must use a different algorithm
> for choosing the right combination of paths. A standard algorithm
> chooses the combination based on cost. For count(*) purposes, the
> decisive factor is that the path has to check all the restrictions, or
> else we'll need heap access to recheck some of them, which defeats the
> purpose of having this optimization. The planner code that builds and
> costs the index path is fairly complex, and integrating this additional
> behavior into it didn't look good to me.
TBH, I'm not sure you need to do any of that work. Have you got evidence
that the planner will fail to choose the right plan regardless? I'm
particularly unconvinced that choose_bitmap_and is a critical problem,
because once you're into having to AND multiple indexes, you're talking
about an expensive query anyhow.
regards, tom lane