Re: query_id, pg_stat_activity, extended query protocol - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: query_id, pg_stat_activity, extended query protocol
Date
Msg-id ZkVbPs9B1e7I8bwK@paquier.xyz
Whole thread Raw
In response to Re: query_id, pg_stat_activity, extended query protocol  ("Imseih (AWS), Sami" <simseih@amazon.com>)
List pgsql-hackers
On Wed, May 15, 2024 at 06:36:23PM +0000, Imseih (AWS), Sami wrote:
>> Okay, that's what I precisely wanted to understand: queryId doesn't have
>> semantics to show the job that consumes resources right now—it is mostly
>> about convenience to know that the backend processes nothing except
>> (probably) this query.
>
> It may be a good idea to expose in pg_stat_activity or a
> supplemental activity view information about the current state of the
> query processing. i.e. Is it parsing, planning or executing a query or
> is it processing a nested query.

pg_stat_activity is already quite bloated with attributes, and I'd
suspect that there are more properties in a query that would be
interesting to track down at a thinner level as long as it mirrors a
dynamic activity of the query.  Perhaps a separate catalog like a
pg_stat_query would make sense, moving query_start there as well?
Catalog breakages are never fun, still always happen because the
reasons behind a backward-incompatible change make the picture better
in the long-term for users.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: CREATE TABLE/ProcessUtility hook behavior change
Next
From: Thomas Munro
Date:
Subject: Re: Why is citext/regress failing on hamerkop?