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

Andrei Lepikhov <lepihov@gmail.com>

From: Andrei Lepikhov <lepihov@gmail.com>

To: Alena Rybakina <a.rybakina@postgrespro.ru>, jian he <jian.universality@gmail.com>, Alexander Korotkov <aekorotkov@gmail.com>

Cc: Nikolay Shaplov <dhyan@nataraj.su>, pgsql-hackers@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org, Peter Geoghegan <pg@bowt.ie>, Marcos Pegoraro <marcos@f10.com.br>, teodor@sigaev.ru, Peter Eisentraut <peter@eisentraut.org>, Ranier Vilela <ranier.vf@gmail.com>

Date: 2024-09-03T09:52:55Z

Lists: pgsql-hackers

Commits

Same data as JSON: 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

Attachments

minor-fix.no-cfbot (text/plain)

On 26/8/2024 12:41, Alena Rybakina wrote:
> On 26.08.2024 06:12, jian he wrote:
>> On Fri, Aug 23, 2024 at 8:58 PM Alexander Korotkov<aekorotkov@gmail.com>  wrote:
>> + int indexnum; /* index of the matching index */
>> + int colnum; /* index of the matching column */
>>
>> I am not 100% sure about the comments.
>> indexnum:  index of the matching index reside in rel->indexlist that
>> matches (counting from 0)
>> colnum: the column number of the matched index (counting from 0)
Hmm, it is not easy to invent an alternative variant. What are you 
proposing exactly?

> If OR constants have different types, then they belong to different 
> groups, and I think that's unfair. I think that conversion to a single 
> type should be used here - while I’m working on this, I’ll send the code 
> in the next letter.
IMO, that means additional overhead, isn't it? It is an improvement and 
I suggest to discuss it in a separate thread if current feature will be 
applied.
> 
> And I noticed that there were some tests missing on this, so I added this.
> 
> I've updated the patch file to include my and Jian's suggestions, as 
> well as the diff file if there's no objection.
I doubt if you really need additional index on the tenk1 table. What is 
the case you can't reproduce with current indexes, playing, let's say, 
with casting to numeric and integer data types?
See in attachment minor fixes to the v38 version of the patch set.

-- 
regards, Andrei Lepikhov