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

From: Thom Brown <thom(at)linux(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Vladimir Borodin <root(at)simply(dot)name>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date: 2016-03-15 14:00:59
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 10 March 2016 at 18:58, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Mar 10, 2016 at 12:18 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> On Wed, Mar 9, 2016 at 7:17 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Wed, Mar 9, 2016 at 8:31 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.


Attachment Content-Type Size
sort_wait_event_doc_table.patch binary/octet-stream 22.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2016-03-15 14:11:59 Re: Minor bug affecting ON CONFLICT lock wait log messages
Previous Message Fabien COELHO 2016-03-15 13:55:52 Re: pgbench - allow backslash-continuations in custom scripts