Re: RFC: replace pg_stat_activity.waiting with something more descriptive
От | Robert Haas |
---|---|
Тема | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Дата | |
Msg-id | CA+TgmoZihhxOHm6AV2=_t9QPvMhjjRUzb=-0-A2KSVnQgKAArQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: RFC: replace pg_stat_activity.waiting with something
more descriptive
Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: