On 08/03/2016 08:47 PM, Andrey Borodin wrote:
1. Currenlty overflow is carried every addition. I suggest that
it is possibe to do it only every (INT32_MAX - INT32_MAX / NBASE) /
(NBASE - 1) addition. Please note that with this overflow count it
will be neccesary to check whether two finishin
On 2016-08-03 17:47:20 +, Andrey Borodin wrote:
> I suppose this proves performance impact of a patch. I don't think
> that sum calculation was a common bottleneck, but certainly patch will
> slightly improve performance of a very huge number of queries.
They commonly are in OLAP style workloa
> 3 авг. 2016 г., в 22:47, Andrey Borodin написал(а):
>
> make installcheck-world: tested, failed
> Implements feature: tested, failed
> Spec compliant: tested, failed
> Documentation:tested, failed
>
> This is a review of a patch "Optimizing numeric SUM() aggregate
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
This is a review of a patch "Optimizing numeric SUM() aggrega
I've tested patch with this query
https://gist.github.com/x4m/fee16ed1a55217528f036983d88771b4
Test specs were: Ubuntu 14 LTS VM, dynamic RAM, hypervisor Windows
Server 2016, SSD disk, core i5-2500. Configuration: out of the box
master make.
On 10 test runs timing of select statement: AVG 3739.8 m
Andrew Borodin writes:
>> I don't think there is any reason for this new code to assume NBASE=1
> There is a comment on line 64 stating that value 1 is hardcoded
> somewhere else, any other value is not recommended and a bunch of code
> is left for historical reasons.
Doesn't matter: ple
On 27 July 2016 at 10:17, Andrew Borodin wrote:
>> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1))
> Woth noting that (INT_MAX - INT_MAX / NBASE) / (NBASE - 1) == INT_MAX
> / NBASE for any NBASE > 1
Interesting. I think it's clearer the way it is in mul_var() though,
because the
On 27 July 2016 at 09:57, Dean Rasheed wrote:
> it could be
> coded using something like
>
> accum->maxdig += NBASE - 1;
> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1))
> Propagate carries...
>
Oops, that's not quite right because maxdig is actually epresents the
> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1))
Woth noting that (INT_MAX - INT_MAX / NBASE) / (NBASE - 1) == INT_MAX
/ NBASE for any NBASE > 1
>I don't think there is any reason for this new code to assume NBASE=1
There is a comment on line 64 stating that value 1 is har
On 27 July 2016 at 07:33, Andrew Borodin wrote:
>>I think we could do carry every 0x7FF / 1 accumulation, couldn't we?
>
> I feel that I have to elaborate a bit. Probably my calculations are wrong.
>
> Lets assume we already have accumulated INT_MAX of digits in
> previous-place accum
>I think we could do carry every 0x7FF / 1 accumulation, couldn't we?
I feel that I have to elaborate a bit. Probably my calculations are wrong.
Lets assume we already have accumulated INT_MAX of digits in
previous-place accumulator. That's almost overflow, but that's not
overflow. C
Hi!
I like the idea and implementation, but I have one suggestion.
> Instead of propagating carry after each new value, it's done only every
> values (or at the end).
I think we could do carry every 0x7FF / 1 accumulation, couldn't we?
Best regards, Andrey Borodin, Octonica & Ural
12 matches
Mail list logo
