Re: [DOCS] Stats views and functions not in order? - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: [DOCS] Stats views and functions not in order?
Date
Msg-id CAKFQuwbQHgBJ4zSA_oKfO6qKvy3S16hx0HuMQGpxmm53MEQJqg@mail.gmail.com
Whole thread Raw
In response to Re: [DOCS] Stats views and functions not in order?  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: [DOCS] Stats views and functions not in order?  (Peter Smith <smithpb2250@gmail.com>)
List 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.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Revoke PUBLIC CREATE from public schema, now owned by pg_databas
Next
From: Tom Lane
Date:
Subject: Re: Allow round() function to accept float and double precision