Thank you for response. Unfortunately, I have to update one section which I wrote wrong, it should have
been this way:
"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
othersdo with this problem?
5. what do you mean by changing pg_stat_statements with another view/table?
LJ
P.S.: The only serious discussion I was able to find about it was from 2015 here, everyone basically stating that the
improvementwould be useful. https://postgrespro.com/list/thread-id/1880012
Sent with Proton Mail secure email.
------- Original Message -------
On Monday, October 2nd, 2023 at 8:50 PM, Wim Bertels <wim.bertels@ucll.be> wrote:
> byme@byme.email schreef op ma 02-10-2023 om 16:19 [+0000]:
>
> > Is there a possibility the pg_stat_statements will be improved with
> > handling IN? This problem makes it so much less useful right now.
>
>
> not sure what the question is,
> but if you change pg_stat_statements with another view/table,
> the problem/answer would be the same
>
> https://www.postgresql.org/docs/current/functions-comparisons.html#FUNCTIONS-COMPARISONS-IN-SCALAR
