Re: In PG12, query with float calculations is slower than PG11
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Emre Hasegeli <emre@hasegeli.com>, nospam-pg-abuse@bloodgate.com,
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-12T19:18:30Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > I do wonder if we're just punching ourselves in the face with the > signature of these checks. Part of the problem here really comes from > using the same function to handle a number of different checks. Yeah, I've thought that too. It's *far* from clear that this thing is a win at all, other than your point about the number of copies of the ereport call. It's bulky, it's hard to optimize, and I have never thought it was more readable than the direct tests it replaced. > For most places it'd probably end up being easier to read and to > optimize if we just wrote them as > if (unlikely(isinf(result)) && !isinf(arg)) > float_overflow_error(); > and when needed added a > else if (unlikely(result == 0) && arg1 != 0.0) > float_underflow_error(); +1 regards, tom lane
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