On 10 April 2014 15:18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dean Rasheed <dean.a.rasheed@gmail.com> writes:
>> On 10 April 2014 01:13, Florian Pflug <fgp@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.
>
Yes, I can imagine that there would be some aggregates for which the
plain forwards transition function would be simpler than the
invertible one, with a simpler state type. You'd still be left with
quite a large number of existing aggregates having non-strict plain
transition functions, in addition to a bunch of new non-strict
invertible transition functions that had to do null counting.
> 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?
>
I was imagining that firsttrans would only be passed the first value
to be aggregated, not any previous state, and that it would be illegal
to specify both an initcond and a firsttrans function.
The forward transition function would only be called for values after
the first, by which point the state would be non-null, and so it could
be made strict in most cases. The same would apply to the invertible
transition functions, so they wouldn't have to do null counting, which
in turn would make their state types simpler.
Regards,
Dean