Re: Add connection active, idle time to pg_stat_activity - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Add connection active, idle time to pg_stat_activity
Date
Msg-id CAKFQuwYeprTF-sxd-4uDKH9CmNecL-N=6wz4TM-X0noXAg9Z8A@mail.gmail.com
Whole thread Raw
In response to Re: Add connection active, idle time to pg_stat_activity  (Andres Freund <andres@anarazel.de>)
Responses Re: Add connection active, idle time to pg_stat_activity
List pgsql-hackers
On Tue, Nov 8, 2022 at 6:56 PM Andres Freund <andres@anarazel.de> wrote:

Separately from that, I'm a bit worried about starting to add accumulative
counters to pg_stat_activity. It's already gotten hard to use interactively
due to the number of columns - and why stop with the columns you suggest? Why
not show e.g. the total number of reads/writes, tuples inserted / deleted,
etc. as well?

I wonder if we shouldn't add a pg_stat_session or such for per-connection
counters that show not the current state, but accumulated per-session state.


I would much rather go down this route than make the existing table wider.

pg_stat_activity_state_duration (this patch) [the table - for a given backend - would be empty if track_activities is off]
pg_stat_activity_bandwidth_usage (if someone feels like implementing the other items you mention)


I'm not really buying into the idea of having multiple states sum their times together.  I would expect one column per state.  Actually two, because I also suggest that not only is the duration recorded, but a counter be incremented each time a given state becomes the currently active state.  Seems like having access to a divisor of some form may be useful.

So 10 columns of data plus pid to join back to pg_stat_activity proper.

David J.

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Add proper planner support for ORDER BY / DISTINCT aggregates
Next
From: Andres Freund
Date:
Subject: Re: allow segment size to be set to < 1GiB