On 10 April 2014 01:13, Florian Pflug <fgp@phlo.org> wrote:
> Also, the *only* reason that SUM(int2|int4) cannot use int8 as it's
> transition type is that it needs to return NULL, not 0, if zero rows
> were aggregates. It might seems that it could just use int8 as state
> with initial value NULL, but that only works if the transition functions
> are non-strict (since the special case of state type == input type doesn't
> apply here). And for non-strict transition functions need to deal with
> NULL inputs themselves, which means counting the number of non-NULL inputs..
>
> That problem would go away though if we had support for an initalfunction,
> which would receive the first input value and initialize the state. In
> the case of SUM(), the initial function would be strict, and thus would be
> called on the first non-NULL input value, which it'd convert to int8 and
> return as the new state.
>
Ah snap!
> However, I still believe the best approach at this point is to just work
> on making int4_avg_accum faster. I still see no principal reason what it
> has to be noticeably slower - the only additional work it absolutely *has*
> to perform is *one* 64-bit increment.
>
In the best case that would make sum() not noticeably slower than
avg(), whereas using a firsttrans/initialfunction would potentially
make both of them faster than they currently are, and not just in
window queries.
Also, IMO a first/initial function leads to a cleaner separation of
logic, allowing some of the transition functions to be simplified
rather than becoming more complex.
Regards,
Dean