Re: In PG12, query with float calculations is slower than PG11
Emre Hasegeli <emre@hasegeli.com>
From: Emre Hasegeli <emre@hasegeli.com>
To: Andres Freund <andres@anarazel.de>
Cc: 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-07T14:42:39Z
Lists: pgsql-hackers
Attachments
- 0001-Bring-back-CHECKFLOATVAL-macro-v01.patch (text/x-patch) patch v1-0001
> > The patch looks unduly invasive to me, but I think that it might be > > right that we should go back to a macro-based implementation, because > > otherwise we don't have a good way to be certain that the function > > parameter won't get evaluated first. > > I'd first like to see some actual evidence of this being a problem, > rather than just the order of the checks. There seem to be enough evidence of this being the problem. We are better off going back to the macro-based implementation. I polished Keisuke Kuroda's patch commenting about the performance issue, removed the check_float*_val() functions completely, and added unlikely() as Tom Lane suggested. It is attached. I confirmed with different compilers that the macro, and unlikely() makes this noticeably faster.
Commits
-
Avoid a performance regression in float overflow/underflow detection.
- 764a554d6f5e 12.3 landed
- 607f8ce74df9 13.0 landed
-
Provide separate header file for built-in float types
- 6bf0bc842bd7 12.0 cited