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

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: David Christensen <david(dot)christensen(at)crunchydata(dot)com>
Cc: Shinya11(dot)Kato(at)nttdata(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] expand the units that pg_size_pretty supports on output
Date: 2021-07-09 07:15:08
Message-ID: CAApHDvoZhMRh3eqqPb53bbQpP1dLO+zukdSjATpbVo3iBTZ3bg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 8 Jul 2021 at 05:44, David Christensen
<david(dot)christensen(at)crunchydata(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2021-07-09 07:16:55 Re: [PoC] Improve dead tuple storage for lazy vacuum
Previous Message Ajin Cherian 2021-07-09 06:56:28 Re: [HACKERS] logical decoding of two-phase transactions