[PROPOSAL] extend the object names to the qualified names inpg_stat_statements - Mailing list pgsql-hackers

From Sergei Agalakov
Subject [PROPOSAL] extend the object names to the qualified names inpg_stat_statements
Date
Msg-id 9baf5c06-d6ab-c688-010c-843348e3d98c@gmail.com
Whole thread Raw
Responses Re: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_stat_ssl additions
Next
From: Thomas Munro
Date:
Subject: Re: "pg_ctl: the PID file ... is empty" at end of make check