Re: pg_walinspect float4/float8 confusion

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_walinspect float4/float8 confusion
Date: 2022-09-12 08:28:38
Message-ID: ae0902bc-852e-51ce-27dd-42e6adcc9bd7@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09.09.22 05:51, Bharath Rupireddy wrote:
> On Thu, Sep 8, 2022 at 5:23 PM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>>
>> The pg_walinspect function pg_get_wal_stats() has output arguments
>> declared as float4 (count_percentage, record_size_percentage, etc.), but
>> the internal computations are all done in type double. Is there a
>> reason why this is then converted to float4 for output? It probably
>> doesn't matter in practice, but it seems unnecessarily confusing. Or at
>> least add a comment so it doesn't look like an accident. Also compare
>> with pgstattuple, which uses float8 in its SQL interface for similar data.
>
> Thanks for finding this. There's no specific reason as such. However,
> it's good to be in sync with what code does internally and what it
> exposes to the users. pg_walinspect uses double data type (double
> precision floating point number) for internal calculations and cuts it
> down to single precision floating point number float4 to the users.
> Attaching a patch herewith. I'm not sure if this needs to be
> backported, if at all, we were to, IMO it should be backported to
> reduce the code diff.

done

> While on, I found that pgstattuple uses uint64 for internal percentile
> calculations as opposed to double data type for others. Attaching a
> small patch to fix it.

Good find. I also changed the computation to use 100.0 instead of 100,
so that you actually get non-integer values out of it.

I didn't backpatch this, since it would probably result in a small
behavior change and the results with the previous code are not wrong,
just unnecessarily truncated.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2022-09-12 08:28:49 Re: broken table formatting in psql
Previous Message bt22kawamotok 2022-09-12 08:25:44 Re: [PATCH]Feature improvement for MERGE tab completion