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+mEY3g@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