On 15 March 2016 at 14:00, Thom Brown <t...@linux.com> wrote: > On 10 March 2016 at 18:58, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Mar 10, 2016 at 12:18 AM, Amit Kapila <amit.kapil...@gmail.com> >> wrote: >>> On Wed, Mar 9, 2016 at 7:17 PM, Robert Haas <robertmh...@gmail.com> wrote: >>>> >>>> On Wed, Mar 9, 2016 at 8:31 AM, Amit Kapila <amit.kapil...@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
sort_wait_event_doc_table_v2.patch
Description: binary/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
