Re: RFC: replace pg_stat_activity.waiting with something more descriptive

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Дата
Msg-id 20160318175459.6g6mpzaszye4m6ia@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Список pgsql-hackers
On 2016-03-18 11:01:04 -0400, Robert Haas wrote:
> 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".

+1. I think categorizing latch waits together will be pretty much
meaningless. We use the same latch for a lot of different things, and
the context in which we're waiting is the important bit.

Andres



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Performance degradation in commit ac1d794
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Performance degradation in commit ac1d794