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

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?

Table 28.2. Collected Statistics Views -- Leave this one unchanged
(per your comments above).

Table 28.12 Wait Events of type LWLock -- Seems a clear case of bad
merging. Alphabetical order is surely needed here, right?

Table 28.34 Additional Statistic Functions -- Alphabetical order would
be a small improvement here, right?

Table 28.35 Per-Backend Statistics Functions -- Alphabetical order
would be a small improvement here, right?

> One thing I'm unhappy about that you didn't address is that
> the subsection ordering in "28.4. Progress Reporting" could
> hardly have been invented even with a dartboard. Perhaps it
> reflects development order, but that's a poor excuse.
> 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.

-----
Kind Regards,
Peter Smith.
Fujitsu Australia.