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 CAEZATCVexJwEoB7p174bj=mVy1t18232hg3WY4ndXe2ASyE=Lw@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 Tue, 6 Jul 2021 at 13:15, David Rowley <dgrowleyml@gmail.com> wrote:
>
> Can you give an example where calling half_rounded too many times will
> give the wrong value? Keeping in mind we call half_rounded the number
> of times that the passed in value would need to be left-shifted by to
> get the equivalent truncated value.
>

./half_rounded 10241 10
1. half_round(10241) == 5121 :: 10241 >> 1 = 5120
2. half_round(5121) == 2561 :: 5120 >> 1 = 2560
3. half_round(2561) == 1281 :: 2560 >> 1 = 1280
4. half_round(1281) == 641 :: 1280 >> 1 = 640
5. half_round(641) == 321 :: 640 >> 1 = 320
6. half_round(321) == 161 :: 320 >> 1 = 160
7. half_round(161) == 81 :: 160 >> 1 = 80
8. half_round(81) == 41 :: 80 >> 1 = 40
9. half_round(41) == 21 :: 40 >> 1 = 20
10. half_round(21) == 11 :: 20 >> 1 = 10

The correct result should be 10 (it would be very odd to claim that
10241 bytes should be displayed as 11kb), but the half-rounding keeps
rounding up at each stage.

That's a general property of rounding -- you need to be very careful
when rounding more than once, since otherwise errors will propagate.
C.f. 4083f445c0, which removed a double-round in numeric sqrt().

To be clear, I'm not saying that the current code half-rounds more
than once, just that it reads as if it does.

Regards,
Dean



pgsql-hackers by date:

Previous
From: "zwj"
Date:
Subject: 回复: Why is XLOG_FPI_FOR_HINT always need backups?
Next
From: Alexander Pyhalov
Date:
Subject: Re: Asymmetric partition-wise JOIN