Re: [PATCH] Negative Transition Aggregate Functions (WIP)

On Tue, Jan 14, 2014 at 2:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>
> One reason I'm thinking this is that whatever we do to ameliorate
> the semantic issues is going to slow down the forward transition
> function --- to no benefit unless the aggregate is being used as a
> window function in a moving window. So I'm less than convinced
> that we *should* implement any of these designs in the default
> aggregates, even if we get to the point where we arguably *could*
> do it with little risk of functional differences.
>
> regards, tom lane
>

I was thinking about this earlier today and came up with an idea that
perhaps aggregates could support 2 transition functions. 1 for normal
aggregation and for windows with UNBOUNDED PRECEDING. The 2nd transition
function could be used when there is a possibility that we would need to
perform an inverse transition. This 2nd transition function could do all
the extra tracking it needed without having to worry that it would slow
down normal aggregation. With numeric that might be tracking each numeric's
scale as it enters and exits the window frame. It might even be possible to
perform inverse transitions with float and double here, we could just
internally use numeric, and have the final function convert back to the
original type. Though perhaps that might have the side effect of making
floating point calculations too accurate? Or at least not matching the IEEE
standards.

Of course, I'm not thinking this could be part of this patch, but I thought
that I'd post the idea while all this is fresh in people's heads.

David