Re: BUG #18790: Pg_stat_statements doesn't track schema. - Mailing list pgsql-bugs

From Raghvendra Mishra
Subject Re: BUG #18790: Pg_stat_statements doesn't track schema.
Date
Msg-id CABZ0CP-OoBLPRCAwCW8R-0DYEvHJUtac0LtikVcbo5+z+AgxAg@mail.gmail.com
Whole thread Raw
In response to BUG #18790: Pg_stat_statements doesn't track schema.  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #18790: Pg_stat_statements doesn't track schema.
List pgsql-bugs
If multiple schema is used in a query then this information can be extracted by parsing the query.
But when the schema is being accessed by setting the search path then it becomes hard to find with which schema
query belongs to in pg_stat_statements.

Thanks for your attention,
Ragh

On Thu, 30 Jan 2025 at 12:10, Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Jan 29, 2025 at 07:10:33PM +0000, PG Bug reporting form wrote:
> Currently, pg_stat_statment doesn't track the schema to which the query
> belongs. In the case of a multitenant database, it becomes hard to find a
> query belonging to which customer is the culprit. It could be solely an
> enhancement, so my question is, Is it useful to expose the schema name also?
> If yes can I contribute to add this support?

Objects from multiple schemas could be used in a single query.  Even
if multiple schemas are tracked, I doubt that the cost of tracking
them is going to be really useful at this level for monitoring.  Or
perhaps you have some specific use case in mind?
--
Michael

pgsql-bugs by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: BUG #18789: logical replication slots are deleted after failovers
Next
From: Greg Sabino Mullane
Date:
Subject: Re: BUG #18790: Pg_stat_statements doesn't track schema.