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

Поиск
Список
Период
Сортировка
От David Christensen
Тема Re: [PATCH] expand the units that pg_size_pretty supports on output
Дата
Msg-id CAOxo6X+kNPEOdEGXs+NiZ_FSLExHgyM2v+gt4yO9=YDX5KgDmQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] expand the units that pg_size_pretty supports on output  (Isaac Morland <isaac.morland@gmail.com>)
Список pgsql-hackers
On Tue, Jun 15, 2021 at 8:31 AM Isaac Morland <isaac.morland@gmail.com> wrote:
On Tue, 15 Jun 2021 at 05:24, <Shinya11.Kato@nttdata.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [bug?] Missed parallel safety checks, and wrong parallel safety
Следующее
От: David Christensen
Дата:
Сообщение: Re: [PATCH] expand the units that pg_size_pretty supports on output