From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | wait event documentation |
Date: | 2017-04-03 13:32:11 |
Message-ID: | CA+Tgmoas00wgz+ngGoo3baVayaA9YHFs2vhv2RmH4WeO4+bqaQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-04-03 13:59:03 | Re: delta relations in AFTER triggers |
Previous Message | Craig Ringer | 2017-04-03 13:12:39 | Re: Rewriting the test of pg_upgrade as a TAP test |