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

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: [PATCH] expand the units that pg_size_pretty supports on output
Дата
Msg-id CAEZATCXnNW4HsmZnxhfezR5FuiGgp+mkY4AzcL5eRGO4fuadWg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] expand the units that pg_size_pretty supports on output  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: [PATCH] expand the units that pg_size_pretty supports on output
Список 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 по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Warn if initdb's --sync-only option is mixed with other options
Следующее
От: Yugo NAGATA
Дата:
Сообщение: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors