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

On Thu, Mar 17, 2016 at 11:10 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Mar 16, 2016 at 10:03 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Wed, Mar 16, 2016 at 5:28 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Tue, Mar 15, 2016 at 9:17 AM, Thomas Reiss <thomas(dot)reiss(at)dalibo(dot)com> wrote:
>>>> Here's a small docpatch to fix two typos in the new documentation.
>>>
>>> Thanks, committed.
>>
>> I just had a quick look at the wait_event committed, and I got a
>> little bit disappointed that we actually do not track latch waits yet,
>> which is perhaps not that useful actually as long as an event name is
>> not associated to a given latch wait when calling WaitLatch. I am not
>> asking for that with this release, this is just for the archive's
>> sake, and I don't mind coding that myself anyway if need be. The
>> LWLock tracking facility looks rather cool btw :)
>
> Yes, I'm quite excited about this. I think it's pretty darn awesome.
>
> I doubt that it would be useful to treat a latch wait as an event.
> It's too generic. You'd want something more specific, like waiting
> for WAL to arrive or waiting for a tuple from a parallel worker or
> waiting to write to the client. It'll take some thought to figure out
> how to organize and categorize that stuff, but it'll also be wicked
> cool.

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.
--
Michael