Re: In PG12, query with float calculations is slower than PG11 - Mailing list pgsql-hackers

From Emre Hasegeli
Subject Re: In PG12, query with float calculations is slower than PG11
Date
Msg-id CAE2gYzxGSyzG1c5wvWSW3oyfqB6D3nUJfYfmJj94uRNRjYi9dA@mail.gmail.com
Whole thread Raw
In response to Re: In PG12, query with float calculations is slower than PG11  (Andres Freund <andres@anarazel.de>)
Responses Re: In PG12, query with float calculations is slower than PG11
Re: In PG12, query with float calculations is slower than PG11
List pgsql-hackers
> > 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.

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: ALTER tbl rewrite loses CLUSTER ON index (consider movingindisclustered to pg_class)
Next
From: Robert Haas
Date:
Subject: Re: [Proposal] Global temporary tables