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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company