From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Greg Stark <stark(at)mit(dot)edu> |
Subject: | Re: Current int & float overflow checking is slow. |
Date: | 2017-10-30 16:59:42 |
Message-ID: | CA+TgmoZgNuniF0ONqEifEM48xoR=pkYVtgfBCcjBwcXtos4mrw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 30, 2017 at 4:57 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> 0001) Introduces pg_{add,sub,mul}{16,32,64}_overflow(a, b, *result)
> These use compiler intrinsics on gcc/clang. If that's not
> available, they cast to a wider type and to overflow checks. For
> 64bit there's a fallback for the case 128bit math is not
> available (here I stole from an old patch of Greg's).
>
> These fallbacks are, as far as I can tell, C free of overflow
> related undefined behaviour.
Looks nice.
> Perhaps it should rather be pg_add_s32_overflow, or a similar
> naming scheme?
Not sure what the s is supposed to be? Signed?
> 0002) Converts int.c, int8.c and a smattering of other functions to use
> the new facilities. This removes a fair amount of code.
>
> It might make sense to split this up further, but right now that's
> the set of functions that either are affected performancewise by
> previous overflow checks, and/or relied on wraparound
> overflow. There's probably more places, but this is what I found
> by visual inspection and compiler warnings.
I lack the patience to review this tonight.
> 0003) Removes -fwrapv. I'm *NOT* suggesting we apply this right now, but
> it seems like an important test for the new facilities. Without
> 0002, tests would fail after this, after it all tests run
> successfully.
I suggest that if we think we don't need -fwrapv any more, we ought to
remove it. Otherwise, we won't find out if we're wrong.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Ivan Kartyshov | 2017-10-30 17:25:18 | Re: make async slave to wait for lsn to be replayed |
Previous Message | Dilip Kumar | 2017-10-30 16:50:01 | Re: path toward faster partition pruning |