Re: Use of additional index columns in rows filtering

On Wed, Aug 9, 2023 at 11:15 AM Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> Cool. I'll try to build my own set of examples that I find interesting
> either because it's what the patch aims to help with, or because I
> expect it to be problematic for some reason. And then we can compare.

That would be great. I definitely want to make this a collaborative thing.

> Yup, I agree with that principle. The AM can evaluate the expression in
> a smarter way, without the visibility checks.

Attached text document (which I guess might be my first draft) is an
attempt to put the discussion up until this point on a more formal
footing.

The format here tries to reduce the principles to a handful of bullet
points. For example, one line reads:

+ Index quals are better than equivalent index filters because bitmap
index scans can only use index quals

I'm pretty sure that these are all points that you and I both agree on
already. But you should confirm that. And make your own revisions, as
you see fit.

It's definitely possible that I overlooked an interesting and durable
advantage that index filters have. If there is some other way in which
index filters are likely to remain the best and only viable approach,
then we should note that. I just went with the really obvious case of
an expression that definitely needs visibility checks to avoid ever
throwing a division-by-zero error, related to some invisible tuple.
It's an extreme case in that it focuses on requirements that seem just
about unavoidable in any future world. (Come to think of it, the
biggest and most durable advantage for index filters is probably just
how general they are, which I do mention.)

--
Peter Geoghegan