On 2014-01-16 14:23:47 -0500, Tom Lane wrote: > > 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. > > Dunno, I think that a transition state containing both an int64 and > a (presumably separately palloc'd) numeric will be a real PITA.
Yea, not sure myself. I just dislike the idea of having a good part of a 128bit math implementation for a single transition function. Another alternative would be a configure check for compiler/native 128bit math and fall back to the current implementation if none is provided... That should give decent performance with a pretty low amount of code for most platforms. > And it will not be faster, because the principal drag on performance > will just be the overflow test, which you have to do either way. Well, you don't need to check the second variable for lots of operations. Say, the current sum is 0 and you add a -1. With the two variables scheme that requires checking the second variable, manipulating it etc. 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
