Re: [PATCH] expand the units that pg_size_pretty supports on output

On Tue, Jun 15, 2021 at 8:31 AM Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
wrote:

> On Tue, 15 Jun 2021 at 05:24, <Shinya11(dot)Kato(at)nttdata(dot)com> wrote:
>
>> >> I don't see the need to extend the unit to YB.
>> >> What use case do you have in mind?
>> >
>> >Practical or no, I saw no reason not to support all defined units. I
>> assume we’ll
>> >get to a need sooner or later. :)
>>
>> Thank you for your reply!
>> Hmmm, I didn't think YB was necessary, but what do others think?
>>
>
> If I’m reading the code correctly, the difference between supporting YB
> and not supporting it is whether there is a line for it in the list of
> prefixes and their multiples. As such, I don’t see why we’re even
> discussing whether or not to include all the standard prefixes. A YB is
> still an absurd amount of storage, but that’s not the point; just put all
> the standard prefixes and be done with it. If actual code changes were
> required in the new code as they are in the old it might be worth
> discussing.
>

Agreed, this is why I went this way. One and done.

> One question: why is there no “k” in the list of prefixes?
>

kB has a special-case code block before you get to this point. I didn't
look into the reasons, but assume there are some.

> Also: why not have only the prefixes in the array, and use a single fixed
> output format "%s %sB" all the time?
>
> It feels like it should be possible to calculate the appropriate idx to
> use (while adjusting the number to print as is done now) and then just have
> one psprintf call for all cases.
>

Sure, if that seems more readable/understandable.

> A more significant question is YB vs. YiB. I know there is a long
> tradition within computer-related fields of saying that k = 1024, M =
> 1024^2, etc., but we’re not special enough to override the more general
> principles of SI (Système International) which provide that k = 1000, M =
> 1000^2 and so on universally and provide the alternate prefixes ki, Mi,
> etc. which use 1024 as the multiple.
>
> So I would suggest either display 2000000 as 2MB or as 1.907MiB.
>

Heh, I was just expanding the existing logic; if others want to have this
particular battle go ahead and I'll adjust the code/prefixes, but obviously
the logic will need to change if we want to support true MB instead of MiB
as MB.

Also, this will presumably be a breaking change for anyone using the
existing units MB == 1024 * 1024, as we've had for something like 20
years. Changing these units to the *iB will be trivial with this patch,
but not looking forward to garnering the consensus to change this part.

David