Re: BUG #18790: Pg_stat_statements doesn't track schema.

From: Raghvendra Mishra <raghshr1351(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18790: Pg_stat_statements doesn't track schema.
Date: 2025-01-30 16:29:41
Message-ID: CABZ0CP-OoBLPRCAwCW8R-0DYEvHJUtac0LtikVcbo5+z+AgxAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)paquier(dot)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
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Greg Sabino Mullane 2025-01-30 18:01:15 Re: BUG #18790: Pg_stat_statements doesn't track schema.
Previous Message Hayato Kuroda (Fujitsu) 2025-01-30 11:48:23 RE: BUG #18789: logical replication slots are deleted after failovers