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 others do 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 improvement would 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@xxxxxxx> 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
