From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Langote <amitlangote09(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, keisuke kuroda <keisuke(dot)kuroda(dot)3862(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: In PG12, query with float calculations is slower than PG11 |
Date: | 2020-02-07 14:42:39 |
Message-ID: | CAE2gYzxGSyzG1c5wvWSW3oyfqB6D3nUJfYfmJj94uRNRjYi9dA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg무지개 토토SQL |
> > 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 | Content-Type | Size |
---|---|---|
0001-Bring-back-CHECKFLOATVAL-macro-v01.patch | text/x-patch | 24.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2020-02-07 15:15:10 | Re: [Proposal] Global temporary tables |
Previous Message | Justin Pryzby | 2020-02-07 14:39:35 | Re: ALTER tbl rewrite loses CLUSTER ON index (consider moving indisclustered to pg_class) |