Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> For int2/int4, we could bump the accumulator to int8 (certainly faster
> than our numeric implementation?), but there are a very few platforms
> which don't support int8 and we shouldn't break the aggregates for
> them.
Right, that's why I preferred the idea of using float8.
Note that any reasonable floating-point implementation will deliver an
exact result for the sum of integer inputs, up to the point at which the
sum exceeds the number of mantissa bits in a float (2^52 or so in IEEE
float8). After that you start to lose accuracy. Using int8 would give
an exact sum up to 2^63, but if we want to start delivering a fractional
average then float still looks like a better deal...
> Tom, do you think that a hack in the aggregate support code which
> compares the pointer returned to the pointer input, then pfree'ing the
> input area if they differ, would fix the major leakage?
Yeah, that would probably work OK, although you'd have to be careful of
the initial condition --- is the initial value always safely pfreeable?
> We could even have a backend global variable which enables/disables
> the feature to allow performance tuning.
Seems unnecessary.
regards, tom lane