From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Emre Hasegeli <emre(at)hasegeli(dot)com>, nospam-pg-abuse(at)bloodgate(dot)com, Amit Langote <amitlangote09(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, keisuke kuroda <keisuke(dot)kuroda(dot)3862(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: In PG12, query with float calculations is slower than PG11 |
Date: | 2020-02-13 17:43:38 |
Message-ID: | 9425.1581615818@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-02-13 18:40:43 | Re: In PG12, query with float calculations is slower than PG11 |
Previous Message | Tom Lane | 2020-02-13 17:42:11 | Re: In PG12, query with float calculations is slower than PG11 |