> Which ones are you concerned about? As of 7.2, the only ones that use > numeric accumulators for non-numeric input types are ...
OK, I did imply that I've been wanting to ask this for some time. I should have asked during the 7.1 era, when this was true for more cases. :) > All of these seem to have good precision/range arguments for using > numeric accumulators, or to be enough off the beaten track that it's > not worth much angst to optimize them. Well, they *are* on the beaten track for someone, just not you! ;) I'd think that things like stddev might be OK with 52 bits of accumulation, so could be done with doubles. Were they implemented that way at one time? Do we have a need to provide precision greater than that, or to guard against the (unlikely) case of having so many values that a double-based accumulator overflows its ability to see the next value? I'll point out that for the case of accumulating so many integers that they can't work with a double, the alternative implementation of using numeric may approach infinite computation time. But in any case, I can ask the same question, only reversed: We now have some aggregate functions which use, say, int4 to accumulate int4 values, if the target platform does *not* support int8. What would it take to make the catalogs configurable or able to respond to configuration results so that, for example, platforms without int8 support could instead use numeric or double values as a substitute? - Thomas ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org