Hi Sergey,
I've done a review of this patch. I found the patch idea very useful,
thank you for the patch. I've noted something observing this patch:
1. Patch can't be applied on the current master. My review is based on
application of this patch over ac68323a878
2. Being applied over ac68323a878 patch works as expected.
3. Field names seems quite long to me (and they should be uniformly
named with the same statistics in other views. For example
"running" term is called "active" in pg_stat_database)
4. Meaningless spaces at the end of line:
- backend_status.c:586
- monitoring.sgml:5857
5. Patch adds
usecs_diff = secs * 1000000 + usecs;
at backend_status.c:pgstat_report_activity() to optimize
calculations. But
pgstat_count_conn_active_time((PgStat_Counter) secs * 1000000 +
usecs);
and
pgstat_count_conn_txn_idle_time((PgStat_Counter) secs * 1000000 +
usecs);
are left in place after that.
6. I'm not sure that I can understand the comment
/* Keep statistics for pg_stat_database intact */
at backend_status.c:600 correctly. Can you please explain it a
little?
7. Tests seems incomplete. It looks like we can check increments in
all fields playing with transactions in tests.
Also, I have a thought about other possible improvements fitting to
this patch.
The view pg_stat_session is really needed in Postgres but I think it
should have much more statistics. I mean all resource statistics
related to sessions. Every backend has instrumentation that tracks
resource consumption. Data of this instrumentation goes to the
cumulative statistics system and is used in monitoring extensions
(like pg_stat_statements). I think pg_stat_session view is able to add
one more dimension of monitoring - a dimension of sessions. In my
opinion this view should provide resource consumption statistics of
current sessions in two cumulative sets of statistics - since backend
start and since transaction start. Such view will be really useful in
monitoring of long running sessions and transactions providing
resource consumption information besides timing statistics.
regards, Andrei Zubkov
Postgres Professional