[PROPOSAL] extend the object names to the qualified names in pg_stat_statements

From: Sergei Agalakov <sergei(dot)agalakov(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements
Date: 2018-11-28 21:18:56
Message-ID: 9baf5c06-d6ab-c688-010c-843348e3d98c@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

It would help to analyze performance issues if pg_stat_statements would
extend the object names to the qualified names.
Currently if we have two schemas ( say s1 and s2) with the objects with
the same name ( say tables t1) then after the next executions:

set schema 's1';
select count(*) from t1; // returns 10
set schema 's2';
select count(*) from t1; // returns 1000000000

we see in
select queryid, query from pg_stat_statements where query like '%from t1%'
  something like this
3004391594 select count(*) from t1
1336375111 select count(*) from t1

We do see that the queries are different but we can't see why they are
so much different in the execution time.
If the pg_stat_statements module would extend the object name to the
qualified names like s1.t1 and s2.t2 in the new column query_qn then we
would see the report as
select queryid, query_qn from pg_stat_statements where query like '%from
t1%'
3004391594 select count(*) from s1.t1
1336375111 select count(*) from s2.t1
with an immediate understanding of what's going on.

This problem isn't only about table names. The SQL statement may refer
to the views, functions, operands etc. from the 'wrong' schema.
Obviously it would be even bigger help in the situations with the more
complex queries where it will be mush more difficult to find
that the query was executed with the incorrect search_path settings.

This change doesn't brake any existing functionality and will be easily
utilized in the monitoring scripts and tools.

Thank you,

Sergei Agalakov

It was discussed in pgsql-general, and now it seems to be ready as a
proposal to pgsql-hackers.
https://www.postgresql.org/message-id/372d75cc-053b-1a07-948f-089408d3cd3a@gmail.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2018-11-28 21:19:30 Re: "pg_ctl: the PID file ... is empty" at end of make check
Previous Message Tom Lane 2018-11-28 21:01:31 Re: pg_stat_ssl additions