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

From Bharath Rupireddy
Subject Re: Add connection active, idle time to pg_stat_activity
Date
Msg-id CALj2ACWKTKwousSpLBipdgL1B9r0AsV9dJTy5_q6eYDNh4LAbQ@mail.gmail.com
Whole thread Raw
In response to Re: Add connection active, idle time to pg_stat_activity  (Rafia Sabih <rafia.pghackers@gmail.com>)
Responses Re: Add connection active, idle time to pg_stat_activity
List pgsql-hackers
On Tue, Nov 16, 2021 at 5:06 PM Rafia Sabih <rafia.pghackers@gmail.com> wrote:
> Got it.
> Updated

Thanks for the patch. +1 for adding the idle/idle_in_txn_time/active
time. I believe these are the total times a backend in its lifetime
accumulates. For instance, if a backend runs 100 txns, then these new
columns show the total time that the backend spent during these 100
txns, right?

Few comments on the patch:

1) Patch is missing a commit message. It is good to have a commit
message describing the high-level of the feature.
2) This patch needs to bump the catalog version, at the end of the
commit message, we usually keep a note "Bump the catalog version".
3) It looks like the documentation is missing [1], for the new columns.
4) When will these backend variables be reset? Is it at the backend
startup? Or some other? If these variables are reset only at the
backend startup and do they keep growing during the entire life of the
backend process? If yes, what happens for a long running backend/user
session, don't they get overflowed?

+
+ int64 st_active_time;
+ int64 st_transaction_idle_time;
+ int64 st_idle_time;
 } PgBackendStatus;

5) Is there any way you can get them tested?
6) What will be entries of st_active_time, st_transaction_idle_time,
st_idle_time for non-backend processes, like bg writer, checkpointer,
parallel worker, bg worker, logical replication launcher, stats
collector, sys logger etc?

[1] https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW

Regards,
Bharath Rupireddy.



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Inconsistent results from seqscan and gist indexscan
Next
From: Tom Lane
Date:
Subject: Re: WIP: WAL prefetch (another approach)