On Tue, 3 Oct 2023 at 22:03, wrote:
> So one last question, should I expect the patch to land in version 17 only or
> is there chance that it will also be in lower versions right away?
It wouldn't ever be put into anything earlier than 17.
David
Thank you very much Laurenz and David. Looking forward to it and unfortunatelly
no, I am not in position to review that...
So one last question, should I expect the patch to land in version 17 only or
is there chance that it will also be in lower versions right away?
LJ
Sent with Proton Mai
On Tue, 2023-10-03 at 08:05 +, byme@byme.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 wou
On Tue, 3 Oct 2023 at 21:07, wrote:
> 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
There is some active discussion and a patch which aims to i
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 b
byme@byme.email schreef op ma 02-10-2023 om 16:19 [+]:
>
>
> 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,
th
Hello,
I would like to ask about a problem that is bothering me for a while now. We
have implemented monitoring of our queries using pg_stat_statements. The only
problem we have with it is that expressions with
IN ('first', 'second', 'third')
get translated into a query as
IN ($1, $2, $3)
and no
