Dean Rasheed <dean.a.rash...@gmail.com> writes: > On 10 April 2014 01:13, Florian Pflug <f...@phlo.org> wrote: >> 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. I'm still of the opinion that we should separate the transfn for invertible cases from the normal one, and allow for two separate state types. One of the things that helps with is the strictness consideration: you no longer have to have the same strictness setting for the plain and invertible forward transfns. This idea of a separate firsttrans function is interesting but perhaps orthogonal to the current patch. Also, I don't quite understand how it would work for aggregates with null initvalues; don't you end up with exactly the same conflict about how you can't mark the transfn strict? Or is the idea that firsttrans would *only* apply to aggregates with null initvalue, and so you wouldn't even pass the previous state value to it? regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers