public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andrei Lepikhov <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: Alena Rybakina <[email protected]>
Cc: Ranier Vilela <[email protected]>
Cc: Alexander Lakhin <[email protected]>
Cc: jian he <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Nikolay Shaplov <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Peter Geoghegan <[email protected]>
Cc: Marcos Pegoraro <[email protected]>
Cc: [email protected]
Cc: Peter Eisentraut <[email protected]>
Subject: Re: POC, WIP: OR-clause support for indexes
Date: Tue, 28 Jan 2025 11:36:47 +0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAPpHfduOn0htAXp6h3gcv1hMUuoQSYfM-sk6TXKcM57C8B4Umw@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<CAPpHfdtPkA3XGM+FOanXfFNm45YEMkuqpfL0ZSL7uOP1bHPPEg@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAEudQApBzH9JNkDpXARrjFG0WGM2PcU02f6Ga9sLVS2H6z9YAQ@mail.gmail.com>
<[email protected]>
<CAPpHfdvM4E-wPCRbYkr9eGH2sSxgOYKZ1iOUyjKYqTEyurFRLQ@mail.gmail.com>
<[email protected]>
<CAPpHfdtgcye9ELaLHw4ZOUxWQ9t1P=oBDJX8KwwOHqasESdXQQ@mail.gmail.com>
<CAPpHfdv+jtNwofg-p5z86jLYZUTt6tR17Wy00ta0dL=wHQN3ZA@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAPpHfdvehQbCpQG9zYr739y2nXQkE=FYsat5VE-pDoB4RDPfBw@mail.gmail.com>
<[email protected]>
<CAPpHfduOn0htAXp6h3gcv1hMUuoQSYfM-sk6TXKcM57C8B4Umw@mail.gmail.com>
On 1/27/25 16:50, Alexander Korotkov wrote:
> I expressed my point on this in [1]. We generally greedy about index
> quals and there is no logic which prevent us from using a clause and
> index qual because of its cost. And there are many cases when this
> causes regressions before d4378c0005. One of examples from [1].
Ok,
Generally, I don't concern myself with the evaluation of individual
subplans. As you mentioned, it should be a rare occurrence when this
becomes important. My main concern is the shift in frequency of
evaluations during execution for various reasons.
For example:
qsort(matches, n, sizeof(OrArgIndexMatch), or_arg_index_match_cmp);
To fit an index, the order of elements in the target array of the
`ScalarArrayOpExpr` may change compared to the initial list of OR
expressions. If there are indexes that cover the same set of columns but
in reverse order, this could potentially alter the position of a
Subplan. However, I believe this is a rare case; it is supported by the
initial OR path and should be acceptable.
So, I do not have any further objections at this time.
--
regards, Andrei Lepikhov
view thread (38+ 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