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  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: GinPageIs* don't actually return a boolean
Следующее
От: Yury Zhuravlev
Дата:
Сообщение: Re: GinPageIs* don't actually return a boolean