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

Hi!

On Wed, Jan 15, 2025 at 10:24 AM Andrei Lepikhov <lepihov@gmail.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

I started reviewing at the patch and saw some output "ERROR" in the output of the test and is it okay here?

-- 
Regards,
Alena Rybakina
Postgres Professional