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

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: 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 03:31:22
Message-ID: 1d5131fc-cd6c-4f61-8ba0-e61c518b168d@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

--
regards, Andrei Lepikhov

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-10-04 03:41:01 Re: query_id, pg_stat_activity, extended query protocol
Previous Message Michael Paquier 2024-10-04 03:21:16 Re: Retire support for OpenSSL 1.1.1 due to raised API requirements