On 07/13/2015 01:36 PM, Amit Kapila wrote:
I have already proposed something very similar in this thread [1]
(where instead of class, I have used wait_event_type) to which
Robert doesn't agree, so here I think before writing code, it seems
prudent to get an agreement about what kind of User-Interface
would satisfy the requirement and will be extendible for future as
well. I think it will be better if you can highlight some points about
what kind of user-interface is better (extendible) and the reasons for
same.
[1] (Refer option-3) -
http://www.postgresql.org/message-id/caa4ek1j6cg_jym00nrwt4n8r78zn4ljoqy_zu1xrzxfq+me...@mail.gmail.com
The idea of splitting to classes and events does not confict with your
current implementation. That is not an issue to show only one value
in pg_stat_activity and more detailed two parameters in other places.
The base reason is that DBA will want to see grouped information about
class (for example wait time of whole `Storage` class).
About user interface it depends from what we want to be monitored. In
our patch we have profiling and history. In profiling we show class,
event, wait_time and count. In history we save all parameters of wait.
Other problem of pg_stat_activity that we can not see all processes
there (checkpointer for example). So we anyway need separate view for
monitoring purposes.
--
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
