On 10 April 2014 01:13, Florian Pflug <f...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
