From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
Cc: | nospam-pg-abuse(at)bloodgate(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-12 17:21:57 |
Message-ID: | 20200212172157.47iw4ofzrpddpq44@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-02-12 11:54:13 +0000, Emre Hasegeli wrote:
> From fb5052b869255ef9465b1de92e84b2fb66dd6eb3 Mon Sep 17 00:00:00 2001
> From: Emre Hasegeli <emre(at)hasegeli(dot)com>
> Date: Fri, 7 Feb 2020 10:27:25 +0000
> Subject: [PATCH] Bring back CHECKFLOATVAL() macro
>
> The inline functions added by 6bf0bc842b caused the conditions of
> overflow/underflow checks to be evaluated when no overflow/underflow
> happen. This slowed down floating point operations. This commit brings
> back the macro that was in use before 6bf0bc842b to fix the performace
> regression.
Wait, no. Didn't we get to the point that we figured out that the
primary issue is the reversal of the order of what is checked is the
primary problem, rather than the macro/inline piece?
Nor do I see how it's going to be ok to just rename the function in a
stable branch.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Phil Florent | 2020-02-12 17:28:58 | Re: Global temporary tables |
Previous Message | Fujii Masao | 2020-02-12 17:01:30 | Re: Minor issues in .pgpass |