Re: wait event documentation - Mailing list pgsql-hackers

From Amit Langote
Subject Re: wait event documentation
Date
Msg-id 70cd6b98-7c3f-e368-04ed-e053d18b7d81@lab.ntt.co.jp
Whole thread Raw
In response to wait event documentation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: wait event documentation  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2017/04/03 22:32, Robert Haas wrote:
> Right now, the information on wait events is organized into one giant
> table inside https://www.postgresql.org/docs/devel/static/monitoring-stats.html#monitoring-stats-views
> -- the wait event type is inserted into the lefthand column of the
> table using moreRows="...", which is awkward to maintain and has
> already provoked several fixup commits after people (including me)
> messed it up.  And indeed it seems to be slightly messed up at the
> moment, too; the LWLock section needs moreRows++.
> 
> Instead of continuing to repair this every time it gets broken, I
> propose that we break this into one table that lists all the
> wait_event_type values -- LWLock, Lock, BufferPin, Activity, Client,
> Extension, IPC, Timeout, and IO -- and then a second table for each
> type that has multiple wait events listing all of the wait events for
> that type.
> 
> I also propose hoisting this out of section 28.2.3 - Viewing
> Statistics - and making it a new toplevel section of chapter 28.  So
> between the current "28.3 Viewing Locks" and the current "28.4
> Progress Reporting" we'd add a new section "Wait Events" and link to
> that from 28.2.3.  That would also give us a place to include any
> general text that we want to have regarding wait events, apart from
> the tables.
> 
> Thoughts?

+1.

By the way, wonder if it wouldn't make sense to take the whole Table 28.1.
Dynamic Statistics Views into a new section (perhaps before 28.2 Viewing
Locks or after), since those views display information different from what
the statistics collector component collects and publishes (those in the
Table 28.2. Collected Statistics Views).

Thanks,
Amit





pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Refactoring identifier checks to consistently usestrcmp
Next
From: Vicky Vergara
Date:
Subject: Instead of DROP function use UPDATE pg_proc in an upgrade extensionscript