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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
