On 10/4/24 03:15, Peter Geoghegan wrote:
> On Tue, Oct 1, 2024 at 6:25 AM Alexander Korotkov <aekorotkov@gmail.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
