Re: [PATCH] expand the units that pg_size_pretty supports on output - Mailing list pgsql-hackers

From David Rowley
Subject Re: [PATCH] expand the units that pg_size_pretty supports on output
Date
Msg-id CAApHDvoZhMRh3eqqPb53bbQpP1dLO+zukdSjATpbVo3iBTZ3bg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] expand the units that pg_size_pretty supports on output  (David Christensen <david.christensen@crunchydata.com>)
List pgsql-hackers
On Thu, 8 Jul 2021 at 05:44, David Christensen
<david.christensen@crunchydata.com> wrote:
> Enclosed is the patch to change the return type to numeric, as well as one for expanding units to
> add PB and EB.

I ended up not changing the return type of pg_size_bytes().

> I figured that PB and EB are probably good enough additions at this point, so we can debate whether
> to add the others.

Per Tom's concern both with changing the return type of
pg_size_bytes() and his and my concern about going too far adding more
units, I've adjusted your patch to only add petabytes and pushed it.
The maximum range of BIGINT is only 8 exabytes, so the BIGINT version
would never show in exabytes anyway. It would still be measuring in
petabytes at the 64-bit range limit.

After a bit of searching, I found reports that the estimated entire
stored digital data on Earth as of 2020 to be 59 zettabytes, or about
0.06 yottabytes.  I feel like we've gone far enough by adding
petabytes today. Maybe that's worth revisiting in a couple of storage
generations. After we're done there, we can start working on the LSN
wraparound code.

David



pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: Masahiko Sawada
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum