Re: RFC: replace pg_stat_activity.waiting with something more descriptive - Mailing list pgsql-hackers

From Thom Brown
Subject Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date
Msg-id CAA-aLv71T2B-356LEXPaDsv-HLUae2AduuKYt1fPoJ_=+=SFXA@mail.gmail.com
Whole thread Raw
In response to Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Thom Brown <thom@linux.com>)
List pgsql-hackers
On 10 March 2016 at 18:58, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Mar 10, 2016 at 12:18 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Wed, Mar 9, 2016 at 7:17 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>
>>> On Wed, Mar 9, 2016 at 8:31 AM, Amit Kapila <amit.kapila16@gmail.com>
>>> wrote:
>>> > Thanks for the suggestion.  I have updated the patch to include
>>> > wait_event_type information in the wait_event table.
>>>
>>> I think we should remove "a server process is" from all of these entries.
>>>
>>> Also, I think this kind of thing should be tightened up:
>>>
>>> +         <entry>A server process is waiting on any one of the
>>> commit_timestamp
>>> +         buffer locks to read or write the commit_timestamp page in the
>>> +         pg_commit_ts subdirectory.</entry>
>>>
>>> I'd just write: Waiting to read or write a commit timestamp buffer.
>>>
>>
>> Okay, changed as per suggestion and fixed the morerows issue pointed by
>> Thom.
>
> Committed with some further editing.  In particular, the way you
> determined whether we could safely access the tranche information for
> any given ID was wrong; please check over what I did and make sure
> that isn't also wrong.
>
> Whew, this was a long process, but we got there.  Some initial pgbench
> testing shows that by far the most common wait event observed on that
> workload is WALWriteLock, which is pretty interesting: perf -e cs and
> LWLOCK_STATS let you measure the most *frequent* wait events, but that
> ignores duration.  Sampling pg_stat_activity tells you which things
> you're spending the most *time* waiting for, which is awfully neat.

It turns out that I hate the fact that the Wait Event Name column is
effectively in a random order.  If a user sees a message, and goes to
look up the value in the wait_event description table, they either
have to search with their browser/PDF viewer, or scan down the list
looking for the item they're looking for, not knowing how far down it
will be.  The same goes for wait event type.

I've attached a patch to sort the list by wait event type and then
wait event name.  It also corrects minor SGML indenting issues.

Thom

Attachment

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pgbench - allow backslash-continuations in custom scripts
Next
From: David Steele
Date:
Subject: Re: [PATCH v6] GSSAPI encryption support