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+TgmoZXtFgucnFHqzWGXjKxeY4pVqA=9hWLVGiG-qe_Sp+X-g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: RFC: replace pg_stat_activity.waiting with something
more descriptive
|
Список | pgsql-hackers |
On Thu, Mar 17, 2016 at 9:22 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > FWIW, my instinctive thought on the matter is to report the event > directly in WaitLatch() via a name of the event caller provided > directly in it. The category of the event is then defined > automatically as we would know its origin. The code path defining the > origin point from where a event type comes from is the critical thing > I think to define an event category. The LWLock events are doing that > in lwlock.c. I'm very skeptical of grouping everything that waits using latches as a latch wait, but maybe it's OK to do it that way. I was thinking more of adding categories like "client wait" with events like "client read" and "client write". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: