Feedback-ID: i131946ab:Fastmail
Message-ID: <ae0902bc-852e-51ce-27dd-42e6adcc9bd7@enterprisedb.com>
Date: Mon, 12 Sep 2022 10:28:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.2
Subject: Re: pg_walinspect float4/float8 confusion
Content-Language: en-US
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
References: <36ee692b-232f-0484-ce94-dc39d82021ad@enterprisedb.com>
 <CALj2ACXbjijc3pwM+=dS7+Jth2-3Pwyx691iVMwZC26hkrj_nQ@mail.gmail.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: 
 <CALj2ACXbjijc3pwM+=dS7+Jth2-3Pwyx691iVMwZC26hkrj_nQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/ae0902bc-852e-51ce-27dd-42e6adcc9bd7%40enterprisedb.com>
Precedence: bulk

On 09.09.22 05:51, Bharath Rupireddy wrote:
> On Thu, Sep 8, 2022 at 5:23 PM Peter Eisentraut
> <peter.eisentraut@enterprisedb.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.