Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Langote <amitlangote09@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Emre Hasegeli <emre@hasegeli.com>, Andres Freund <andres@anarazel.de>, keisuke kuroda <keisuke.kuroda.3862@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-02-06T18:31:07Z
Lists: pgsql-hackers 
On Thu, Feb 6, 2020 at 11:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So it appears to me that what commit 6bf0bc842 did in this area was
> not just wrong, but disastrously so.  Before that, we had a macro that
> evaluated isinf(val) before it evaluated the inf_is_valid condition.
> Now we have check_float[48]_val which do it the other way around.
> That would be okay if the inf_is_valid condition were cheap to
> evaluate, but in common code paths it's actually twice as expensive
> as isinf().

Well, if the previous coding was a deliberate attempt to dodge this
performance issue, the evidence seems to be well-concealed. Neither
the comments for that macro nor the related commit messages make any
mention of it. When subtle things like this are performance-critical,
good comments are pretty critical, too.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

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

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