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

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(dot)lepikhov(at)postgrespro(dot)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