Re: In PG12, query with float calculations is slower than PG11
От | Andres Freund |
---|---|
Тема | Re: In PG12, query with float calculations is slower than PG11 |
Дата | |
Msg-id | 20200212193244.xgcr6ghzrnajme5k@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: In PG12, query with float calculations is slower than PG11 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: In PG12, query with float calculations is slower than PG11
Re: In PG12, query with float calculations is slower than PG11 |
Список | 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
В списке pgsql-hackers по дате отправления: