Re: POC, WIP: OR-clause support for indexes

On Wed, Jan 15, 2025 at 10:24 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
> On 1/13/25 10:39, Andrei Lepikhov wrote:
> > On 1/13/25 01:39, Alexander Korotkov wrote:
> > It can be resolved with a single-line change (see attached). But I need
> > some time to ponder over the changing behaviour when a clause may match
> > an index and be in joinorclauses.
> In addition, let me raise a couple of issues:
> 1. As Robert has said before, it may interfere with some short-circuit
> optimisations like below:
>
> EXPLAIN (COSTS OFF)
> SELECT * FROM bitmap_split_or t1
> WHERE t1.a=2 AND (t1.b=2 OR t1.b = (
> SELECT sum(c1.reltuples) FROM pg_class c1, pg_class c2
> WHERE c1.relpages=c2.relpages AND c1.relpages = t1.a));
>
> Here, a user may avoid evaluating the subplan at all if t1.b=2 all the
> time when t1.a=2. OR->ANY may accidentally shift this behaviour.
>
> 2. The query:
>
> EXPLAIN (ANALYZE, COSTS OFF)
> SELECT * FROM bitmap_split_or t1
> WHERE t1.a=2 OR t1.a = (
> SELECT sum(c1.reltuples) FROM pg_class c1, pg_class c2
> WHERE c1.relpages=c2.relpages AND c1.relpages = t1.a)::integer;
>
> causes SEGFAULT during index keys evaluation. I haven't dived into it
> yet, but it seems quite a typical misstep and is not difficult to fix.

Segfault appears to be caused by a typo. Patch used parent rinfo
instead of child rinfo. Fixed in the attached patch.

It appears that your first query also changed a plan after fixing
this. Could you, please, provide another example of a regression for
short-circuit optimization, which is related to this patch?

Also, I've integrated your fix from [1].

Links.
1. https://www.postgresql.org/message-id/41ba3d47-2a48-476c-88d4-6ebd889a7af2%40gmail.com

------
Regards,
Alexander Korotkov
Supabase