Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Emre Hasegeli <emre@hasegeli.com>
Cc: nospam-pg-abuse@bloodgate.com, Tom Lane <tgl@sss.pgh.pa.us>, Amit Langote <amitlangote09@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, keisuke kuroda <keisuke.kuroda.3862@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-02-12T17:21:57Z
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@hasegeli.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

Commits

  1. Avoid a performance regression in float overflow/underflow detection.

  2. Provide separate header file for built-in float types