Horton

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

Alena Rybakina <a.rybakina@postgrespro.ru>

View thread
From: Alena Rybakina <a.rybakina@postgrespro.ru>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>, jian he <jian.universality@gmail.com>, 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-04T15:31:36Z
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 →

  1. Make group_similar_or_args() reorder clause list as little as possible

  2. Allow usage of match_orclause_to_indexcol() for joins

  3. Skip not SOAP-supported indexes while transforming an OR clause into SAOP

  4. Remove the wrong assertion from match_orclause_to_indexcol()

  5. Teach bitmap path generation about transforming OR-clauses to SAOP's

  6. Transform OR-clauses to SAOP's during index matching

  7. Fix the value of or_to_any_transform_limit in postgresql.conf.sample

  8. Transform OR clauses to ANY expression

  9. MergeAttributes code deduplication

  10. SEARCH and CYCLE clauses

  11. Improve estimation of OR clauses using extended statistics.

  12. Teach btree to handle ScalarArrayOpExpr quals natively.

  13. Revise collation derivation method and expression-tree representation.

  14. Instead of trying to force WHERE clauses into CNF or DNF normal form,

Attachments

Hi!

On 03.09.2024 12:52, Andrei Lepikhov wrote:
>> 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.
I think we will have a slight overhead, so in essence it will go 
additionally through the transformed groups, and not through the entire 
list of Or expressions. I agree with your suggestion to discuss it in 
separate thread.
>>
>> 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.
>
I rewrote the tests with integer types. Thanks for your suggestion. If 
you don't mind, I've updated the diff file you attached earlier to 
include the tests.