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: Alexander Korotkov <aekorotkov@gmail.com>, Andrei Lepikhov <a.lepikhov@postgrespro.ru>, jian he <jian.universality@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org, Peter Geoghegan <pg@bowt.ie>, "Finnerty, Jim" <jfinnert@amazon.com>, Marcos Pegoraro <marcos@f10.com.br>, teodor@sigaev.ru, Tomas Vondra <tomas.vondra@enterprisedb.com>, Peter Eisentraut <peter@eisentraut.org>, Ranier Vilela <ranier.vf@gmail.com>
Date: 2024-03-03T09:48:19Z
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,

Sorry, I found explanation - 
https://www.postgresql.org/message-id/CACJufxFS-xcjaWq2Du2OyJUjRAyqCk12Q_zGOPxv61sgrdpw9w%40mail.gmail.com

On 03.03.2024 12:26, Alena Rybakina wrote:
>
> I found that it was mentioned here - 
> https://www.postgresql.org/message-id/CACJufxFrZS07oBHMk1_c8P3A84VZ3ysXiZV8NeU6gAnvu%2BHsVA%40mail.gmail.com.
>
> To be honest, I couldn't find any explanation for that.
>
> On 01.03.2024 18:33, Alexander Korotkov wrote:
>> Hi, Andrei,
>> Hi, Alena!
>>
>> On Thu, Feb 29, 2024 at 10:59 AM Andrei Lepikhov 
>> <a.lepikhov@postgrespro.ru> wrote:
>>
>>     On 28/2/2024 17:27, Alena Rybakina wrote:
>>     > Maybe like that:
>>     >
>>     > It also considers the way to generate a path using BitmapScan
>>     indexes,
>>     > converting the transformed expression into expressions
>>     separated by "OR"
>>     > operations, and if it turns out to be the best and finally
>>     selects the
>>     > best one.
>>     Thanks,
>>     I spent some time describing the feature with documentation.
>>     A condensed description of the GUC is in the runtime-config file.
>>     Feature description has spread between TransformOrExprToANY and
>>     generate_saop_pathlist routines.
>>     Also, I've made tiny changes in the code to look more smoothly.
>>     All modifications are integrated into the two new patches.
>>
>>     Feel free to add, change or totally rewrite these changes.
>>
>>
>> I'm going to review and revise the patch.
>>
>> One question I have yet.
>>
>> >        /*
>> >         * Transformation only works with both side type is not
>> >         * { array | composite | domain | record }.
>>
>> Why do we limit transformation for these types?  Also, it doesn't 
>> seem the current code restricts anything except composite/record.
>>
>> ------
>> Regards,
>> Alexander Korotkov
> -- 
> Regards,
> Alena Rybakina
> Postgres Professional:http://www.postgrespro.com
> The Russian Postgres Company

-- 
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company