| From: | John Naylor <johncnaylorls(at)gmail(dot)com> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Fix floating-point noise in pg_stat_us_to_ms() |
| Date: | 2026-07-01 09:05:23 |
| Message-ID: | CANWCAZZshCiYyU7HPWDRMbr6Dq2UdPggJTECeiCyL39Kg8e+6A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 29, 2026 at 2:02 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> Hi hackers,
>
> while reviewing [1], I noticed that the IO timings displayed in pg_stat_io can
> produce floating-point noise like:
>
> postgres=# select read_time from pg_stat_io where read_time > 0;
> read_time
> ---------------------
> 2.2640000000000002
> 0.08700000000000001
>
> That's because 0.001 cannot be represented exactly in binary floating
> point. I think this output looks weird, even if understandable. Note that with
> extra_float_digits set to 0 you don't see the noise (but 1 is the default).
Yes, multiplying by that constant also multiplies the rounding error.
> Given that / 1000.0 is the most common way to do this kind of computation in the
> code tree, I think that it makes sense to update pg_stat_us_to_ms() to do so.
+1, I'll take care of this.
--
John Naylor
Amazon Web Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | solai v | 2026-07-01 09:15:02 | Re: [PATCH] Add pg_get_policy_ddl() function to reconstruct CREATE POLICY statement |
| Previous Message | Bertrand Drouvot | 2026-07-01 08:38:16 | Re: Add pg_stat_kind_info system view |