Re: Optimizing numeric SUM() aggregate

From: Andrew Borodin <borodin(at)octonica(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimizing numeric SUM() aggregate
Date: 2016-07-27 09:17:51
Message-ID: CAJEAwVGMbqamZvzd+xKF4i92benSeze6_jg0ikfuGVX-fHQkBA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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=10000
There is a comment on line 64 stating that value 10000 is hardcoded
somewhere else, any other value is not recommended and a bunch of code
is left for historical reasons.

Best regards, Andrey Borodin, Octonica & Ural Federal University.

2016-07-27 13:57 GMT+05:00 Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>:
> On 27 July 2016 at 07:33, Andrew Borodin <borodin(at)octonica(dot)com> wrote:
>>>I think we could do carry every 0x7FFFFFF / 10000 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 9999 digits in
>> previous-place accumulator. That's almost overflow, but that's not
>> overflow. Carring that accumulator to currents gives us INT_MAX/10000
>> carried sum.
>> So in current-place accumulator we can accumulate: ( INT_MAX - INT_MAX
>> / 10000 ) / 9999, where 9999 is max value dropped in current-place
>> accumulator on each addition.
>> That is INT_MAX * 9999 / 99990000 or simply INT_MAX / 10000.
>>
>> If we use unsigned 32-bit integer that is 429496. Which is 43 times
>> less frequent carring.
>>
>> As a bonus, we get rid of 9999 const in the code (:
>>
>> Please correct me if I'm wrong.
>>
>
> This is basically the same problem that has already been solved in
> mul_var() and other places in numeric.c, so in this case it could be
> coded using something like
>
> accum->maxdig += NBASE - 1;
> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1))
> Propagate carries...
>
> I agree that the new code should avoid explicitly referring to
> constants like 9999, and I don't think there is any reason for this
> new code to assume NBASE=10000.
>
> Regards,
> Dean

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2016-07-27 09:40:34 Re: Optimizing numeric SUM() aggregate
Previous Message Dean Rasheed 2016-07-27 08:57:47 Re: Optimizing numeric SUM() aggregate