On 2014-01-16 21:07:33 +0200, Heikki Linnakangas wrote: > On 01/16/2014 08:59 PM, Tom Lane wrote: > >Heikki Linnakangas <hlinnakan...@vmware.com> writes: > >>I propose that we reimplement sum(bigint) in a more efficient way: For > >>the internal state, let's use an int8 and a numeric overflow field. The > >>transition function adds to the int8 variable, and checks for overflow. > >>On overflow, increment the numeric field by one. In the final function, > >>multiply the numeric by 2^64, and add the residual int8 value. > > > >It'd probably be sufficient to handle it as two int64 fields (handmade > >128-bit arithmetic, or maybe even not so handmade if that ever gets > >reasonably common among C compilers). > > True. That would be sufficient for summing 2^64 int8s of INT64_MAX. That > sounds like enough, especially considering that that count() will overflow > after that too.
You'll have to handle adding negative values and underflow as well. Maybe it's instead sufficient to just have flag indicating that you're working with a state that hasn't overflowed so far and just plain int8 math as long as that's the case, and entirely fall back to the current path once overflowed. That will probably be slightly faster and easily handle the majority of cases since overflowing int8 ought to be pretty rare in the real world. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
