Re: RFC: replace pg_stat_activity.waiting with something more descriptive
От | Robert Haas |
---|---|
Тема | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Дата | |
Msg-id | CA+Tgmoaenh_fzT=8VnODWX569X+mU_LgkZ2XOuNgH=i1MCm_tA@mail.gmail.com обсуждение исходный текст |
Ответ на | 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 Thu, Jun 25, 2015 at 11:57 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> >> 3. Add new view 'pg_stat_wait_event' with following info: >> >> pid - process id of this backend >> >> waiting - true for any form of wait, false otherwise >> >> wait_event_type - Heavy Weight Lock, Light Weight Lock, I/O wait, etc >> >> wait_event - Lock (Relation), Lock (Relation Extension), etc >> I am pretty unconvinced that it's a good idea to try to split up the >> wait event into two columns. I'm only proposing ~20 wait states, so >> there's something like 5 bits of information here. Spreading that >> over two text columns is a lot, and note that Amit's text would >> basically recapitulate the contents of the first column in the second >> one, which I cannot get excited about. > There is an advantage in splitting the columns which is if wait_event_type > column indicates Heavy Weight Lock, then user can go and check further > details in pg_locks, I think he can do that even by seeing wait_event > column, but that might not be as straightforward as with wait_event_type > column. It's just a matter of writing event_type LIKE 'Lock %' instead of event_type = 'Lock'. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: