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
|
Список | 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 по дате отправления: