Re: In PG12, query with float calculations is slower than PG11

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

In response to

Responses

Browse pgsql-hackers by date

  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