Re: pg_stat_statements and "IN" conditions

On Wed, 14 Aug 2024 at 01:06, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
>
> > On Sun, Aug 11, 2024 at 09:34:55PM GMT, Dmitry Dolgov wrote:
> > > On Sun, Aug 11, 2024 at 07:54:05PM +0300, Sergei Kornilov wrote:
> > >
> > > This feature will improve my monitoring. Even in patch 0001. I think there are many other people in the thread who think this is useful. So maybe we should move it forward? Any complaints about the overall design? I see in the discussion it was mentioned that it would be good to measure performance difference.
> > >
> > > PS: patch cannot be applied at this time, it needs another rebase.
> >
> > Yeah, it seems like most people are fine with the first patch and the
> > simplest approach. I'm going to post a rebased version and a short
> > thread summary soon.
>
> Ok, here is the rebased version. If anyone would like to review them, below is
> the short summary of the thread. Currently the patch series contains 4 changes:
>
> * 0001-Prevent-jumbling-of-every-element-in-ArrayExpr.patch
>
> Implements the simplest way to handle constant arrays, if the array contains
> only constants it will be reduced. This is the basis, if I read it correctly
> Nathan and Michael expressed that they're mostly fine with this one.
>
> Michael seems to be skeptical about the "merged" flag in the LocationLen
> struct, but from what I see the proposed alternative has problems as well.
> There was also a note that the loop over constants has to be benchmarked, but
> it's not entirely clear for me in which dimentions to benchmark (i.e. what
> are the expectations). For both I'm waiting on a reply to my questions.
>
> * 0002-Reusable-decimalLength-functions.patch
>
> A small refactoring to make already existing "powers" functonality reusable
> for following patches.
>
> * 0003-Merge-constants-in-ArrayExpr-into-groups.patch
>
> Makes handling of constant arrays smarter by taking into account number of
> elements in the array. This way records are merged into groups power of 10,
> i.e. arrays with length 55 will land in a group 10-99, with lenght 555 in a
> group 100-999 etc. This was proposed by Alvaro, and personally I like this
> approach, because it remediates the issue of one-size-fits-all for the static
> threshold. But there are opinions that this introduces too much complexity.
>
> * 0004-Introduce-query_id_const_merge_threshold.patch
>
> Fine tuning for the previous patch, makes only arrays with the length over a
> certain threshold to be reduced.
>
> On top of that Yasuo Honda and Jakub Wartak have provided a couple of practical
> examples, where handling of constant arrays has to be improved. David Geier
> pointed out some examples that might be confusing as well. All those are
> definitely worth addressing, but out of scope of this patch for now.

Hi! Can you please send a rebased version of this?

--
Best regards,
Kirill Reshke