On Mon, Oct 30, 2017 at 11:24 PM, Andres Freund wrote:
>> > Perhaps it should rather be pg_add_s32_overflow, or a similar
>> > naming scheme?
>>
>> Not sure what the s is supposed to be? Signed?
>
> Yes, signed. So we could add a u32 or something complementing the
> functions already
Robert Haas writes:
>> 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'
Hi,
On 2017-10-30 22:29:42 +0530, Robert Haas wrote:
> On Mon, Oct 30, 2017 at 4:57 PM, Andres Freund 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 a
On Mon, Oct 30, 2017 at 4:57 PM, Andres Freund 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 fo
Hi,
On 2017-10-24 03:39:54 -0700, Andres Freund wrote:
> Largely that's due to the overflow checks.
>
> For integers we currently do:
>
> #define SAMESIGN(a,b) (((a) < 0) == ((b) < 0))
>
> /*
>* Overflow check. If the inputs are of different signs then their sum
>* cannot ov
On 2017-10-24 15:28:17 -0400, Tom Lane wrote:
> Also, if I recall the old discussion properly, one concern was getting
> uniform behavior across different platforms. I'm worried that if we do
> what Andres suggests, we'll get behavior that is not only different but
> platform-specific. Now, to th
On 2017-10-25 07:33:46 +0200, Robert Haas wrote:
> On Tue, Oct 24, 2017 at 9:28 PM, Tom Lane wrote:
> > I don't like changing well-defined, user-visible query behavior for
> > no other reason than a performance gain (of a size that hasn't even
> > been shown to be interesting, btw). Will we chang
On Tue, Oct 24, 2017 at 9:28 PM, Tom Lane wrote:
> I don't like changing well-defined, user-visible query behavior for
> no other reason than a performance gain (of a size that hasn't even
> been shown to be interesting, btw). Will we change it back in another
> ten years if the performance trade
Robert Haas writes:
> On Tue, Oct 24, 2017 at 4:36 PM, Tom Lane wrote:
>> Yeah, but I lost the argument. For better or worse, our expected
>> behavior is now that we throw errors. You don't get to change that
>> just because it would save a few cycles.
> I don't know that we can consider the r
On Tue, Oct 24, 2017 at 4:36 PM, Tom Lane wrote:
>> Does it? In plenty of cases getting infinity rather than an error is
>> just about as useful.
>> This was argued by a certain Tom Lane a few years back ;)
>> http://archives.postgresql.org/message-id/19208.1167246902%40sss.pgh.pa.us
>
> Yeah, but
Andres Freund writes:
> On 2017-10-24 10:09:09 -0400, Tom Lane wrote:
>> There's an ancient saying that code can be arbitrarily fast if it
>> doesn't have to get the right answer. I think this proposal falls
>> in that category.
> Does it? In plenty of cases getting infinity rather than an error
On 2017-10-24 10:09:09 -0400, Tom Lane wrote:
> Andres Freund writes:
> > There's no comparable overflow handling to the above integer
> > intrinsics. But I think we can still do a lot better. Two very different
> > ways:
>
> > 1) Just give up on detecting overflows for floats. Generating inf in
Andres Freund writes:
> There's no comparable overflow handling to the above integer
> intrinsics. But I think we can still do a lot better. Two very different
> ways:
> 1) Just give up on detecting overflows for floats. Generating inf in
>these cases actually seems entirely reasonable. We al
We already know this integer overflow checking is non-standard and
compilers keep trying to optimize them out. Our only strategy to
defeat that depends on compiler flags like -fwrapv that vary by
compiler and may or may not be working on less well tested compiler.
So if there's a nice readable an
Hi,
In analytics queries that involve a large amounts of integers and/or
floats (i.e. a large percentage) it's quite easy to see the functions
underlying the operators in profiles. Partially that's the function call
overhead, but even *after* removing most of that via JITing, they're
surprisingly
15 matches
Mail list logo
