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

From Dean Rasheed
Subject Re: [PATCH] expand the units that pg_size_pretty supports on output
Date
Msg-id CAEZATCXnNW4HsmZnxhfezR5FuiGgp+mkY4AzcL5eRGO4fuadWg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] expand the units that pg_size_pretty supports on output  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: [PATCH] expand the units that pg_size_pretty supports on output  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Wed, 7 Jul 2021 at 03:47, David Rowley <dgrowleyml@gmail.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



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Warn if initdb's --sync-only option is mixed with other options
Next
From: Yugo NAGATA
Date:
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors