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

From: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
To: Andrei Lepikhov <lepihov(at)gmail(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Nikolay Shaplov <dhyan(at)nataraj(dot)su>, pgsql-hackers(at)lists(dot)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org, Peter Geoghegan <pg(at)bowt(dot)ie>, Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>, teodor(at)sigaev(dot)ru, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: POC, WIP: OR-clause support for indexes
Date: 2025-01-30 13:22:55
Message-ID: CALT9ZEHS76SfGQBuxXYVNRWX4GhfZtZoD9KsxVn-PsMkYB9W+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 28 Jan 2025 at 12:42, Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>
> On 1/28/25 11:36, Andrei Lepikhov wrote:
> > On 1/27/25 16:50, Alexander Korotkov wrote:
> > qsort(matches, n, sizeof(OrArgIndexMatch), or_arg_index_match_cmp);
> >
> > To fit an index, the order of elements in the target array of the
> > `ScalarArrayOpExpr` may change compared to the initial list of OR
> > expressions. If there are indexes that cover the same set of columns but
> > in reverse order, this could potentially alter the position of a
> > Subplan. However, I believe this is a rare case; it is supported by the
> > initial OR path and should be acceptable.
> I beg your pardon - I forgot that we've restricted the feature's scope
> and can't combine OR clauses into ScalarArrayOpExpr if the args list
> contains references to different columns.
> So, my note can't be applied here.
>
> --
> regards, Andrei Lepikhov

I've looked at the patch v46-0001
Looks good to me.

There is a test that demonstrates the behavior change. Maybe some more
cases like are also worth adding to a test.

+SELECT * FROM bitmap_split_or t1, bitmap_split_or t2 WHERE t1.a=t2.c
OR (t1.a=t2.b OR t1.a=1);
+ QUERY PLAN
+--------------------------------------------------------
+ Nested Loop
+ -> Seq Scan on bitmap_split_or t2
+ -> Index Scan using t_a_b_idx on bitmap_split_or t1
+ Index Cond: (a = ANY (ARRAY[t2.c, t2.b, 1]))
+(4 rows)
+
+EXPLAIN (COSTS OFF)
+SELECT * FROM bitmap_split_or t1, bitmap_split_or t2 WHERE t1.c=t2.b OR t1.a=1;
+ QUERY PLAN
+----------------------------------------------
+ Nested Loop
+ Join Filter: ((t1.c = t2.b) OR (t1.a = 1))
+ -> Seq Scan on bitmap_split_or t1
+ -> Materialize
+ -> Seq Scan on bitmap_split_or t2
+(5 rows)
+
+EXPLAIN (COSTS OFF)

Comment
> * Also, add any potentially usable join OR clauses to *joinorclauses
may reflect the change in v46-0001 lappend -> list_append_unique_ptr
that differs in the processing of equal clauses in the list.

Semantics mentioned in the commit message:
> 2. Make match_join_clauses_to_index() pass OR-clauses to
> match_clause_to_index().
could also be added as comments in the section just before
match_join_clauses_to_index()

Since d4378c0005e6 comment for match_clause_to_indexcol() I think
needs change. This could be as a separate commit, not regarding
current patch v46-0001.
> * NOTE: returns NULL if clause is an OR or AND clause; it is the
> * responsibility of higher-level routines to co

I think the patch can be pushed with possible additions to regression
test and comments.

Regards,
Pavel Borisov
Supabase

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2025-01-30 13:26:29 Re: Compression of bigger WAL records
Previous Message Nazir Bilal Yavuz 2025-01-30 13:18:54 Re: Windows CFBot is broken because ecpg dec_test.c error