Re: Use of additional index columns in rows filtering

On Tue, Aug 8, 2023 at 7:28 AM Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> Are you sure? Because if I try with the 20230716 patch, I get this plan
> (after disabling bitmapscan):

> So the condition is recognized as index filter. Or did you mean
> something different?

No, I was just wrong about this (and about inequalities in general). I
now see why the planner preferred a bitmap scan, which makes sense.
Apologies.

> Not sure. A couple messages back I suggested that maybe there is a way
> to check which expression would be safe to evaluate before checking the
> visibility. This seems similar, although what you're suggesting really
> applies to the "transformed" SAOP, and I'm not sure it can be extended
> to the original SAOP.

The transformation doesn't necessarily have to happen in order for it
to be possible in principle (and correct). My point was that there are
a handful of important types of expressions (SAOPs among them, but
possibly also RowCompareExpr and IS NULL tests) that are "index quals
in spirit". These expressions therefore don't seem to need visibility
checks at all -- the index qual guarantees "apply transitively".

It's possible that an approach that focuses on leakproof quals won't
have any problems, and will be strictly better than "extending the
index qual guarantees to index-qual-like expressions". Really not sure
about that.

In any case I see a huge amount of value in differentiating between
cases that need visibility checks (if only via the VM) and those that
do not, ever. I'm speaking very generally here -- nothing to do with
my adversarial tenk1 test case. It's weird that index quals have such
a massive advantage over even simple index filters -- that feels
artificial. I suggest that you focus on that aspect, since it has the
potential to make what is already a compelling patch into a much more
compelling patch.

--
Peter Geoghegan