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 | CAKFQuwYtjTbYUs+bLUCk7aszXq_rHx0Fj=0e0fiaVKyDZ9k0Yw@mail.gmail.com Whole thread Raw |
| In response to | Re: [DOCS] Stats views and functions not in order? (Peter Smith <smithpb2250@gmail.com>) |
| Responses |
Re: [DOCS] Stats views and functions not in order?
|
| List | pgsql-hackers |
On Mon, Nov 7, 2022 at 5:19 PM Peter Smith <smithpb2250@gmail.com> wrote:
On Mon, Nov 7, 2022 at 5:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Smith <smithpb2250@gmail.com> writes:
> > Sorry, I forgot the attachments in the previous post. PSA.
>
> I spent a bit of time looking at this. I agree that a lot of the
> current ordering choices here look like they were made with the
> advice of a dartboard, and there's a number of things that are
> pretty blatantly just sloppy merging (like the out-of-order
> wait-event items). However, I'm not a big fan of "alphabetical
> order at all costs", because that frequently leads to ordering
> decisions that are not a lot better than random from a semantic
> standpoint. For example, I resist the idea that it's sensible
> to put pg_stat_all_indexes before pg_stat_all_tables.
> I'm unconvinced that putting pg_stat_sys_tables and
> pg_stat_user_tables far away from pg_stat_all_tables is great,
> either.
>
Thanks for taking the time to look at my patch. The "at all costs"
approach was not the intention - I was just trying only to apply some
sane ordering where I did not recognize a reason for the current
order.
> So ... how do we proceed?
>
To proceed with the existing patches I need some guidance on exactly
which of the changes can be considered improvements versus which ones
are maybe just trading one 'random' order for another.
How about below?
Table 28.1. Dynamic Statistics Views -- Alphabetical order would be a
small improvement here, right?
The present ordering seems mostly OK, though just like the "Progress" update below the bottom 6 pg_stat_progress_* entries should be alphabetized; but leaving them as a group at the end seems desirable.
Move pg_stat_recovery_prefetch either after subscription or after activity - the replication/received/subscription stuff all seems like it should be grouped together. As well as the security related ssl/gssapi.
Table 28.2. Collected Statistics Views -- Leave this one unchanged
(per your comments above).
I would suggest moving the 3 pg_statio_*_tables rows between the pg_stat_*_tables and the pg_stat_xact_*_tables groups.
Everything pertaining to cluster, database, tables, indexes, functions. slru and replication slots should likewise shift to the (near) top in the cluster/database grouping.
Table 28.12 Wait Events of type LWLock -- Seems a clear case of bad
merging. Alphabetical order is surely needed here, right?
+1 Agreed.
Table 28.34 Additional Statistic Functions -- Alphabetical order would
be a small improvement here, right?
No. All "reset" items should be grouped at the end like they are. I don't see an alternative ordering among them that is clearly superior. Same for the first four.
Table 28.35 Per-Backend Statistics Functions -- Alphabetical order
would be a small improvement here, right?
This one I would rearrange alphabetically. Or, at least, I have a different opinion of what would make a decent order but it doesn't seem all that clearly better than alphabetical.
> I'd be inclined to alphabetize by SQL command name, but maybe
> leave Base Backup to the end since it's not a SQL command.
>
Yes, I had previously only looked at the content of section 28.2
because I didn't want to get carried away by changing too much until
there was some support for doing the first part.
Now PSA a separate patch for fixing section "28.4. Progress Reporting"
order as suggested.
This seems like a clear win.
David J.
pgsql-hackers by date: