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

On Wed, 7 Jul 2021 at 03:47, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> Updated patch attached.
>

Hmm, this looked easy, but...

It occurred to me that there ought to be regression tests for the edge
cases where it steps from one unit to the next. So, in the style of
the existing regression tests, I tried the following:

SELECT size, pg_size_pretty(size), pg_size_pretty(-1 * size) FROM
(VALUES (10239::bigint), (10240::bigint),
(10485247::bigint), (10485248::bigint),
(10736893951::bigint), (10736893952::bigint),
(10994579406847::bigint), (10994579406848::bigint),
(11258449312612351::bigint), (11258449312612352::bigint)) x(size);

size | pg_size_pretty | pg_size_pretty
-------------------+----------------+----------------
10239 | 10239 bytes | -10239 bytes
10240 | 10 kB | -10 kB
10485247 | 10239 kB | -10 MB
10485248 | 10 MB | -10 MB
10736893951 | 10239 MB | -10 GB
10736893952 | 10 GB | -10 GB
10994579406847 | 10239 GB | -10 TB
10994579406848 | 10 TB | -10 TB
11258449312612351 | 10239 TB | -10239 TB
11258449312612352 | 10240 TB | -10239 TB
(10 rows)

SELECT size, pg_size_pretty(size), pg_size_pretty(-1 * size) FROM
(VALUES (10239::numeric), (10240::numeric),
(10485247::numeric), (10485248::numeric),
(10736893951::numeric), (10736893952::numeric),
(10994579406847::numeric), (10994579406848::numeric),
(11258449312612351::numeric), (11258449312612352::numeric)) x(size);

size | pg_size_pretty | pg_size_pretty
-------------------+----------------+----------------
10239 | 10239 bytes | -10239 bytes
10240 | 10 kB | -10 kB
10485247 | 10239 kB | -10239 kB
10485248 | 10 MB | -10 MB
10736893951 | 10239 MB | -10239 MB
10736893952 | 10 GB | -10 GB
10994579406847 | 10239 GB | -10239 GB
10994579406848 | 10 TB | -10 TB
11258449312612351 | 10239 TB | -10239 TB
11258449312612352 | 10240 TB | -10240 TB
(10 rows)

Under the assumption that what we're trying to achieve here is
schoolbook rounding (ties away from zero), the numeric results are
correct and the bigint results are wrong.

The reason is that bit shifting isn't the same as division for
negative numbers, since bit shifting rounds towards negative infinity
whereas division rounds towards zero (truncates), which is what I
think we really need.

Regards,
Dean