Re: [DOCS] Stats views and functions not in order?
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Peter Smith <smithpb2250@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-12-01T14:35:15Z
Lists: pgsql-hackers
On Thu, Dec 1, 2022 at 2:20 AM Peter Eisentraut < peter.eisentraut@enterprisedb.com> wrote: > On 29.11.22 08:29, Peter Smith wrote: > > PSA v8* patches. > > > > Here, patches 0001 and 0002 are unchanged, but 0003 has many changes > > per David's suggestion [1] to change all these views to <refentry> > > blocks. > > I don't understand what order 0001 is trying to achieve. The rule behind 0001 is: All global object stats All table object stats (stat > statio > xact; all > sys > user) All index object stats All sequence object stats All function object stats > As an aside, I find the mixing of pg_stat_* and pg_statio_* views > visually distracting. It was easier to read before when they were in > separate blocks. > I found that having the statio at the end of each object type block added a natural partitioning for tables and indexes that the existing order lacked and that made reading the table be more "wall-of-text-ish", and thus more difficult to read, than necessary. I'm not opposed to the following though. The object-type driven order just feels more useful but I really cannot justify it beyond that. I'm not particularly enamored with the existing single large table but don't have a better structure to offer at this time. > I think something like this would be manageable: > > <!-- everything related to global objects, alphabetically --> > pg_stat_archiver > pg_stat_bgwriter > pg_stat_database > pg_stat_database_conflicts > pg_stat_replication_slots > pg_stat_slru > pg_stat_subscription_stats > pg_stat_wal > WAL being adjacent to archiver/bgwriter seemed reasonable so I left that alone. Replication and Subscription being adjacent seemed reasonable so I left that alone. Thus slru ended up last, with database* remaining as-is. At 8 items, with a group size average of 2, pure alphabetical is also reasonable. > <!-- all "stat" for schema objects, by "importance" --> > > <!-- all "statio" for schema objects, by "importance" --> > > David J.
Commits
-
doc: Re-order Table 28.2 "Collected Statistics Views"
- 72e0ff2677c4 16.0 landed
-
doc: Re-order Table 28.35 "Per-Backend Statistics Functions"
- b1d0158060f3 16.0 landed
-
doc: Re-order Table 28.12 "Wait Events of type LWLock"
- 9c558b94f0ca 16.0 landed
-
doc: Re-order sections of "28.4. Progress Reporting"
- 6573643501e9 16.0 landed