Re: RFC: replace pg_stat_activity.waiting with something more descriptive
От | Ildus Kurbangaliev |
---|---|
Тема | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Дата | |
Msg-id | 55A3ACC3.6020907@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: RFC: replace pg_stat_activity.waiting with something
more descriptive
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: