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

From Amit Langote
Subject Re: In PG12, query with float calculations is slower than PG11
Date
Msg-id CA+HiwqFhXZU6-G+7YJuNk+NPOns=o=pOKvA-rZzGEsW_NEJPOQ@mail.gmail.com
Whole thread Raw
In response to Re: In PG12, query with float calculations is slower than PG11  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: In PG12, query with float calculations is slower than PG11
List pgsql-hackers
On Fri, Feb 7, 2020 at 11:43 PM Emre Hasegeli <emre@hasegeli.com> wrote:
> > > 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.

Thanks for updating the patch.

Should we update the same macro in contrib/btree_gist/btree_utils_num.h too?

Regards,
Amit



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: WAL usage calculation patch
Next
From: Fujii Masao
Date:
Subject: pg_basebackup -F plain -R overwrites postgresql.auto.conf