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