Horton

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

Emre Hasegeli <emre@hasegeli.com>

View thread View on postgr.es
From: Emre Hasegeli <emre@hasegeli.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-13T16:25:25Z
Lists: pgsql-hackers

Attachments

> > > > 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?
>
> Yes, I am happy to do.  It makes more sense to me too.

How about the one attached?

Commits

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

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