On Fri, Oct 4, 2024 at 6:31 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
>
> 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?
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
