Re: POC, WIP: OR-clause support for indexes
Andrei Lepikhov <lepihov@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Make group_similar_or_args() reorder clause list as little as possible
- 775a06d44c04 18.0 landed
-
Allow usage of match_orclause_to_indexcol() for joins
- 627d63419e22 18.0 landed
-
Skip not SOAP-supported indexes while transforming an OR clause into SAOP
- 5bba0546eecb 18.0 landed
-
Remove the wrong assertion from match_orclause_to_indexcol()
- d4d11940df94 18.0 landed
-
Teach bitmap path generation about transforming OR-clauses to SAOP's
- ae4569161a27 18.0 landed
-
Transform OR-clauses to SAOP's during index matching
- d4378c0005e6 18.0 landed
-
Fix the value of or_to_any_transform_limit in postgresql.conf.sample
- 2af75e117478 17.0 landed
-
Transform OR clauses to ANY expression
- 72bd38cc99a1 17.0 landed
-
MergeAttributes code deduplication
- 64444ce071f6 17.0 cited
-
SEARCH and CYCLE clauses
- 3696a600e229 14.0 cited
-
Improve estimation of OR clauses using extended statistics.
- 25a9e54d2db3 14.0 cited
-
Teach btree to handle ScalarArrayOpExpr quals natively.
- 9e8da0f75731 9.2.0 cited
-
Revise collation derivation method and expression-tree representation.
- b310b6e31ce5 9.1.0 cited
-
Instead of trying to force WHERE clauses into CNF or DNF normal form,
- 9888192fb773 8.0.0 cited
On 10/17/24 03:39, Alexander Korotkov wrote: > On Wed, Oct 16, 2024 at 7:22 AM Andrei Lepikhov <lepihov@gmail.com> wrote: >> On 10/12/24 21:25, Alexander Korotkov wrote: >>> I forgot to specify (COSTS OFF) for EXPLAINs in regression tests. Fixed in v42. >> I've passed through the patch set. >> >> Let me put aside the v42-0003 patch—it looks debatable, and I need time >> to analyse the change in regression tests caused by this patch. > > Yes, 0003 patch is for illustration purposes for now. I will not keep > rebasing it. We can pick it later when main patches are committed. Got it. I will save it into the TODO list. > >> Comments look much better according to my current language level. Ideas >> with fast exits also look profitable and are worth an additional >> 'matched' variable. >> >> So, in general, it is ok. I think only one place with >> inner_other_clauses can be improved. Maybe it will be enough to create >> this list only once, outside 'foreach(j, groupedArgs)' cycle? Also, the >> comment on the necessity of this operation was unclear to me. See the >> attachment for my modest attempt at improving it. > > Thank you, I've integrated your patch with minor edits from me. Thanks, I'm not sure about necessity to check NIL value of a list (list_free also do it), but I'm ok with the edits. -- regards, Andrei Lepikhov