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

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Andrei Lepikhov <lepihov(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>, jian he <jian(dot)universality(at)gmail(dot)com>, Nikolay Shaplov <dhyan(at)nataraj(dot)su>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>, teodor(at)sigaev(dot)ru, Peter Eisentraut <peter(at)eisentraut(dot)org>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Subject: Re: POC, WIP: OR-clause support for indexes
Date: 2024-10-04 11:45:18
Message-ID: CAPpHfdvmS2i13p4jzPG+tc-KpfBJedtmf1vP5tVJhZVRawJdRw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 4, 2024 at 6:31 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>
> On 10/4/24 03:15, Peter Geoghegan wrote:
> > On Tue, Oct 1, 2024 at 6:25 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> >> I think this patchset got much better, and it could possible be
> >> committed after another round of cleanup and comment/docs improvement.
> >> It would be very kind if you share your view on the decisions made in
> >> this patchset.
> Let me provide a standpoint to help Alexander.
>
> The origin reason was - to avoid multiple BitmapOr, which has some
> effects at the planning stage (memory consumption, planning time) and
> execution (execution time growth). IndexScan also works better with a
> single array (especially a hashed one) than with a long list of clauses.
> Another reason is that by spending some time identifying common operator
> family and variable-side clause equality, we open a way for future cheap
> improvements like removing duplicated constants.
> Who knows, maybe we will be capable of using this code to improve
> cardinality estimations.
>
> According to your proposal, we have had such casting to the common type
> in previous versions. Here, we avoid it intentionally: the general idea
> is about long lists of constants, and such casting causes questions
> about performance. Do I want it in the core? Yes, I do! But may we
> implement it a bit later to have time to probe the general method and
> see how it flies?

Andrei, thank you for your opinion. Just for the record, I'm still
exploring this and will reply later today or tomorrow.

------
Regards,
Alexander Korotkov
Supabase

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2024-10-04 12:16:00 Re: Set query_id for query contained in utility statement
Previous Message Peter Eisentraut 2024-10-04 11:02:04 Re: Rename PageData to XLogPageData