On Tue, Nov 8, 2022 at 6:56 PM Andres Freund <and...@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.
