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:
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
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 |