Re: In PG12, query with float calculations is slower than PG11 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: In PG12, query with float calculations is slower than PG11
Date
Msg-id 20200212183742.shlgzccoddlnqjrz@alap3.anarazel.de
Whole thread Raw
In response to Re: In PG12, query with float calculations is slower than PG11  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: In PG12, query with float calculations is slower than PG11
List pgsql-hackers
Hi,

On 2020-02-12 13:15:22 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I'd just rename the macro to the name of the inline function. No need to
> > have a verbose change in all callsites just to update the name imo.
>
> +1, that's what I had in mind too.  That does suggest though that we
> ought to make sure the macro has single-eval behavior, so that you
> don't need to know it's a macro.

We'd have to store 'val' in a local variable for that I think. Not the
prettiest, but also not a problem.


I do wonder if we're just punching ourselves in the face with the
signature of these checks. Part of the problem here really comes from
using the same function to handle a number of different checks.

I mean something like dtof's
    check_float4_val((float4) num, isinf(num), num == 0);
where the num == 0 is solely to satisfy the check function is a bit
stupid.

And the reason we have these isinf(arg1) || isinf(arg2) parameters is
also largely because we force the same function to be used in cases
where we have two inputs, rather than just one.

For most places it'd probably end up being easier to read and to
optimize if we just wrote them as

if (unlikely(isinf(result)) && !isinf(arg))
    float_overflow_error();

and when needed added a

else if (unlikely(result == 0) && arg1 != 0.0)
    float_underflow_error();

the verbose piece really is the error, not the error check. Sure, there
are more complicated cases like

if (unlikely(isinf(result)) && (!isinf(arg1) || !isinf(arg2)))

but that's still not very complicated.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: assert pg_class.relnatts is consistent
Next
From: Julien Rouhaud
Date:
Subject: Re: Collation versioning