Re: pg_stat_statements IN problem

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: byme(at)byme(dot)email, Wim Bertels <wim(dot)bertels(at)ucll(dot)be>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_stat_statements IN problem
Date: 2023-10-03 08:54:17
Message-ID: f0254aba438399af2fb69110cfc5c71fd4cacb08.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 2023-10-03 at 08:05 +0000, byme(at)byme(dot)email wrote:
> "This obfuscates our monitoring because the same query with different amount of arguments gets translated into this:
> IN ($1, $2)
> and so on."
>
> The questions are:
> 1. Shouldnt IN behave so that the query in pg_stat_statements would look like this:
> IN $1
> 2. Shouldnt there be at least some flag to aggregate such queries into one?
> 3. Is there any workaround how to aggregate those queries except the "= ANY"?
> 4. How come no one is bothered by this if this makes pg_stat_statements unusable with lots of queries using IN, what others do with this problem?
> 5. what do you mean by changing pg_stat_statements with another view/table?

There is currently a patch for this very problem under review:

https://commitfest.postgresql.org/44/2837/

The discussion is here:

https://www.postgresql.org/message-id/flat/CA+q6zcWtUbT_Sxj0V6HY6EZ89uv5wuG5aefpe_9n0Jr3VwntFg(at)mail(dot)gmail(dot)com

You could comment on that patch or review it. Useful reviews and supporting
comments help move the patch forward. That would best serve your interests.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message byme 2023-10-03 09:03:33 Re: pg_stat_statements IN problem
Previous Message Sergey Cherukhin 2023-10-03 08:51:16 Re: Operating of synchronous master when no standby is available