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

Andres Freund <andres@anarazel.de> writes:
> On 2020-02-13 16:25:25 +0000, Emre Hasegeli wrote:
>> And also this commit is changing the usage of unlikely() to cover
>> the whole condition.  Using it only for the result is not semantically
>> correct.  It is more than likely for the result to be infinite when
>> the input is, or it to be 0 when the input is.

> I'm not really convinced by this fwiw.

> Comparing

>     if (unlikely(isinf(result) && !isinf(num)))
>         float_overflow_error();

> with

>     if (unlikely(isinf(result)) && !isinf(num))
>         float_overflow_error();

> I don't think it's clear that we want the former. What we want to
> express is that it's unlikely that the result is infinite, and that the
> compiler should optimize for that. Since there's a jump involved between
> the check for isinf(result) and the one for !isinf(num), we want the
> compiler to implement this so the non-overflow path follows the first
> check, and the rest of the check is later.

Yeah, I was wondering about that.  I'll change it as you suggest.

            regards, tom lane