Re: Add connection active, idle time to pg_stat_activity

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Add connection active, idle time to pg_stat_activity
Дата
Msg-id CAKFQuwYeprTF-sxd-4uDKH9CmNecL-N=6wz4TM-X0noXAg9Z8A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add connection active, idle time to pg_stat_activity  (Andres Freund <andres@anarazel.de>)
Ответы Re: Add connection active, idle time to pg_stat_activity  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Add proper planner support for ORDER BY / DISTINCT aggregates
Следующее
От: Andres Freund
Дата:
Сообщение: Re: allow segment size to be set to < 1GiB