Subject: Re: Add support for unit "B" to pg_size_pretty()

From: Dean Rasheed <[email-masked]>
Date: Thu, 2 Mar 2023 20:32:26 +0000

On Thu, 2 Mar 2023 at 19:58, David Rowley <[email-masked]> wrote:
>
> I think I'd prefer to see the size_bytes_unit_alias struct have an
> index into size_pretty_units[] array. i.e:
>
> struct size_bytes_unit_alias
> {
>     const char *alias; /* aliased unit name */
>     const int unit_index; /* corresponding size_pretty_units element */
> };
>
> then the pg_size_bytes code can be simplified to:
>
> /* If not found, look in the table of aliases */
> if (unit->name == NULL)
> {
>     for (const struct size_bytes_unit_alias *a = size_bytes_aliases;
> a->alias != NULL; a++)
>     {
>         if (pg_strcasecmp(strptr, a->alias) == 0)
>         {
>             unit = &size_pretty_units[a->unit_index];
>             break;
>         }
>     }
> }
>
> which saves having to have the additional and slower nested loop code.
>

Hmm, I think it would be easier to just have a separate table for
pg_size_bytes(), rather than reusing pg_size_pretty()'s table. I.e.,
size_bytes_units[], which would only need name and multiplier columns
(not round and limit). Done that way, it would be easier to add other
units later (e.g., non-base-2 units).

Also, it looks to me as though the doc change is for pg_size_pretty()
instead of pg_size_bytes().

Regards,
Dean

---

From: David Rowley <[email-masked]>
Date: Sat, 4 Mar 2023 00:23:21 +1300

> units later (e.g., non-base-2 units).

Maybe that's worthwhile if we were actually thinking of adding any
non-base 2 units in the future, but if we're not, perhaps it's better
just to have the smaller alias array which for Peter's needs will just
require 1 element + the NULL one instead of 6 + NULL.

In any case, I'm not really sure I see what the path forward would be
to add something like base-10 units would be for pg_size_bytes(). If
we were to change MB to mean 10^6 rather than 2^20 I think many people
would get upset.

David

---

From: Dean Rasheed <[email-masked]>
Date: Fri, 3 Mar 2023 12:22:38 +0000

On Fri, 3 Mar 2023 at 11:23, David Rowley <[email-masked]> wrote:
> > pg_size_bytes(), rather than reusing pg_size_pretty()'s table.
>

Maybe. It's the tradeoff between having a smaller array and more code
(2 loops) vs a larger array and less code (1 loop).

> we were to change MB to mean 10^6 rather than 2^20 I think many people

Yeah, that's probably true. Given the way this and configuration
parameters currently work, I think we're stuck with 1MB meaning 2^20
bytes.

Regards,
Dean