On Thu, Nov 10, 2022 at 10:04 AM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
...
>> > 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_*
entriesshould 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
stuffall 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
shiftto 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
thatis 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
orderbut 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.
Thanks for the review and table ordering advice. AFAICT I have made
all the changes according to the suggestions.
Each re-ordering was done as a separate patch (so maybe they can be
pushed separately, in case some but not all are OK). PSA.
~~
I was also wondering (but have not yet done) if the content *outside*
the tables should be reordered to match the table 28.1/28.2 order.
e.g. Currently it is not quite the same:
CURRENT
28.2.3. pg_stat_activity
28.2.4. pg_stat_replication
28.2.5. pg_stat_replication_slots
28.2.6. pg_stat_wal_receiver
28.2.7. pg_stat_recovery_prefetch
28.2.8. pg_stat_subscription
28.2.9. pg_stat_subscription_stats
28.2.10. pg_stat_ssl
28.2.11. pg_stat_gssapi
28.2.12. pg_stat_archiver
28.2.13. pg_stat_bgwriter
28.2.14. pg_stat_wal
28.2.15. pg_stat_database
28.2.16. pg_stat_database_conflicts
28.2.17. pg_stat_all_tables
28.2.18. pg_stat_all_indexes
28.2.19. pg_statio_all_tables
28.2.20. pg_statio_all_indexes
28.2.21. pg_statio_all_sequences
28.2.22. pg_stat_user_functions
28.2.23. pg_stat_slru
SUGGESTED
28.2.3. pg_stat_activity
28.2.4. pg_stat_replication
28.2.6. pg_stat_wal_receiver
28.2.7. pg_stat_recovery_prefetch
28.2.8. pg_stat_subscription
28.2.10. pg_stat_ssl
28.2.11. pg_stat_gssapi
28.2.12. pg_stat_archiver
28.2.13. pg_stat_bgwriter
28.2.14. pg_stat_wal
28.2.15. pg_stat_database
28.2.16. pg_stat_database_conflicts
28.2.23. pg_stat_slru
28.2.5. pg_stat_replication_slots
28.2.17. pg_stat_all_tables
28.2.18. pg_stat_all_indexes
28.2.19. pg_statio_all_tables
28.2.20. pg_statio_all_indexes
28.2.21. pg_statio_all_sequences
28.2.22. pg_stat_user_functions
28.2.9. pg_stat_subscription_stats
Thoughts?
------
Kind Regards,
Peter Smith.
Fujitsu Australia
