Re: wait event documentation

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: wait event documentation
Date: 2017-04-04 03:57:31
Message-ID: 70cd6b98-7c3f-e368-04ed-e053d18b7d81@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vicky Vergara 2017-04-04 04:17:55 Instead of DROP function use UPDATE pg_proc in an upgrade extension script
Previous Message Alvaro Herrera 2017-04-04 03:52:57 Re: Refactoring identifier checks to consistently use strcmp