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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
