Re: Add support for unit "B" to pg_size_pretty() - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Add support for unit "B" to pg_size_pretty()
Date
Msg-id CAEZATCXhckx67SNMduA9Qh=5Px2bkCp7oeW4M8+P54eWHdorgw@mail.gmail.com
Whole thread Raw
In response to Re: Add support for unit "B" to pg_size_pretty()  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Fri, 3 Mar 2023 at 11:23, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Fri, 3 Mar 2023 at 09:32, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> > 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.
>
> 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.
>

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

> 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.
>

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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Missing update of all_hasnulls in BRIN opclasses
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: [Proposal] Add foreign-server health checks infrastructure