Re: [DOCS] Stats views and functions not in order?

On Mon, Nov 7, 2022 at 5:19 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:

> On Mon, Nov 7, 2022 at 5:50 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Peter Smith <smithpb2250(at)gmail(dot)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.