pg_stat_statements IN problem

From: byme(at)byme(dot)email
To: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: pg_stat_statements IN problem
Date: 2023-10-02 16:19:40
Message-ID: Z6FGe-JBOEhPm3AUulSOJc7z5UiSbr3U_N88tmBbXyNbwZLolx8kV7i8qBuJHYxI64cYcsXnV-2ynh1VBr3uK6doMBtuUkYXtpH70keFNYQ=@byme.email
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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 not as
IN $1

This obfuscates our monitoring because the same query with different amount of arguments get translated into this:
IN ('first', 'second')
and so on.

I was trying to find some discussions about it, but could not find much. One suggestion was to use
= ANY
but that is a problem when using some third party framework for db operations, in our case for python, for example web2py's DAL or sqlalchemy.

Is there a possibility the pg_stat_statements will be improved with handling IN? This problem makes it so much less useful right now.

Or is there something I could do to have the statistics for such queries aggreageted? Or is there something else I am missing?

Best regards

Lukas Jerabek

Sent with [Proton Mail](https://proton.me/) secure email.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Karl O. Pinc 2023-10-02 16:49:42 Trigger functions and parallelism
Previous Message Adrian Klaver 2023-10-02 16:10:49 Re: pg_agent jobs