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:

Reply via email to