Re: In PG12, query with float calculations is slower than PG11
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
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:32:44Z
Lists: pgsql-hackers
Hi, On 2020-02-12 14:18:30 -0500, Tom Lane wrote: > 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 Cool. Emre, any chance you could write a patch along those lines? I'm inclined that we should backpatch that, and just leave the inline function (without in core callers) in place in 12? Greetings, Andres Freund
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