Subject: Re: pg_stat_statements and "IN" conditions

From: Dmitry Dolgov <[email-masked]>
Date: Sat, 26 Mar 2022 18:40:35 +0100

> On Mon, Mar 14, 2022 at 04:51:50PM +0100, Dmitry Dolgov wrote:
> > On Mon, Mar 14, 2022 at 11:38:23AM -0400, Tom Lane wrote:
> > Dmitry Dolgov <[email-masked]> writes:
> > > On Mon, Mar 14, 2022 at 11:23:17AM -0400, Tom Lane wrote:
> > >> I do find it odd that the proposed patch doesn't cause the *entire*
> > >> list to be skipped over.  That seems like extra complexity and confusion
> > >> to no benefit.
> >
> > > That's a bit surprising for me, I haven't even thought that folks could
> > > think this is an odd behaviour. As I've mentioned above, the original
> > > idea was to give some clues about what was inside the collapsed array,
> > > but if everyone finds it unnecessary I can of course change it.
> >
> > But if what we're doing is skipping over an all-Consts list, then the
> > individual Consts would be elided from the pg_stat_statements entry
> > anyway, no?  All that would remain is information about how many such
> > Consts there were, which is exactly the information you want to drop.
>
> Hm, yes, you're right. I guess I was thinking about this more like about
> shortening some text with ellipsis, but indeed no actual Consts will end
> up in the result anyway. Thanks for clarification, will modify the
> patch!

Here is another iteration. Now the patch doesn't leave any trailing
Consts in the normalized query, and contains more documentation. I hope
it's getting better.

---

From: Dmitry Dolgov <[email-masked]>
Date: Sun, 24 Jul 2022 12:06:36 +0200

> On Sat, Mar 26, 2022 at 06:40:35PM +0100, Dmitry Dolgov wrote:

Hi,

Here is the rebased version, with no other changes.

---

From: Sergei Kornilov <[email-masked]>
Date: Fri, 16 Sep 2022 21:25:13 +0300

Hello!

Unfortunately the patch needs another rebase due to the recent split of guc.c (0a20ff54f5e66158930d5328f89f087d4e9ab400)

I'm reviewing a patch on top of a previous commit and noticed a failed test:

#   Failed test 'no parameters missing from postgresql.conf.sample'
#   at t/003_check_guc.pl line 82.
#          got: '1'
#     expected: '0'
# Looks like you failed 1 test of 3.
t/003_check_guc.pl .............. 

The new option has not been added to the postgresql.conf.sample

PS: I would also like to have such a feature. It's hard to increase pg_stat_statements.max or lose some entries just because some ORM sends requests with a different number of parameters.

regards, Sergei

---

From: Dmitry Dolgov <[email-masked]>
Date: Sat, 24 Sep 2022 16:07:14 +0200

> On Fri, Sep 16, 2022 at 09:25:13PM +0300, Sergei Kornilov wrote:
> Hello!
>

Thanks! I'll post the rebased version soon.

---

From: Dmitry Dolgov <[email-masked]>
Date: Sun, 25 Sep 2022 01:59:39 +0200

> On Sat, Sep 24, 2022 at 04:07:14PM +0200, Dmitry Dolgov wrote:

And here it is.