public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andrei Lepikhov <[email protected]>
To: Peter Geoghegan <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Alena Rybakina <[email protected]>
Cc: jian he <[email protected]>
Cc: Nikolay Shaplov <[email protected]>
Cc: [email protected]
Cc: Robert Haas <[email protected]>
Cc: [email protected]
Cc: Marcos Pegoraro <[email protected]>
Cc: [email protected]
Cc: Peter Eisentraut <[email protected]>
Cc: Ranier Vilela <[email protected]>
Subject: Re: POC, WIP: OR-clause support for indexes
Date: Fri, 4 Oct 2024 10:31:22 +0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAH2-WznLiw20U_Tp8Otm=g7hGcfWnodM4EOGzV=F3W-EvfQDTw@mail.gmail.com>
References: <[email protected]>
<CAPpHfduFJHTNGCTFWt4GFs-E6Ts8xS5mCsKOYKBsZAmoOr8ZSA@mail.gmail.com>
<[email protected]>
<CAPpHfdtR3cBKCSj_7dd7EDF_pa-rUUQBx3-guK6kZZ=_hSeMfg@mail.gmail.com>
<[email protected]>
<CAPpHfdvF864n=Lzmjd2XBi9TwboZvrhRtLSt2hCP+JVUv6XKzg@mail.gmail.com>
<CACJufxHCJvC3X8nUK-jRvRru-ZEXp16EBPADOwTGaqmOYM1Raw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAPpHfduBA9RXa1LQAz=wFK8cGx_AaHVK_vnNqCnG4yA7KwFf7g@mail.gmail.com>
<[email protected]>
<CAPpHfds4wGdWQ2xx1OUKZC4ggqS6Q=cBSck9Re1ajY0ESkwcmw@mail.gmail.com>
<CAPpHfdswA8ucBOuyf6GEn93ffC-oG7EjuvRprXx5Zc7Qdgafqw@mail.gmail.com>
<CAH2-WznLiw20U_Tp8Otm=g7hGcfWnodM4EOGzV=F3W-EvfQDTw@mail.gmail.com>
On 10/4/24 03:15, Peter Geoghegan wrote:
> On Tue, Oct 1, 2024 at 6:25 AM Alexander Korotkov <[email protected]> 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
view thread (78+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: POC, WIP: OR-clause support for indexes
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox