From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [DOCS] Stats views and functions not in order? |
Date: | 2022-12-01 14:35:15 |
Message-ID: | CAKFQuwbQHgBJ4zSA_oKfO6qKvy3S16hx0HuMQGpxmm53MEQJqg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 1, 2022 at 2:20 AM Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-12-01 14:39:53 | Re: Allow round() function to accept float and double precision |
Previous Message | Tom Lane | 2022-12-01 14:24:43 | Re: pgsql: Revoke PUBLIC CREATE from public schema, now owned by pg_databas |