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

On 15 March 2016 at 14:00, Thom Brown <thom@linux.com> wrote:
> 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.

Let's try that again, this time without duplicating a row, and omitting another.

Thom