On Tue, Jan 14, 2014 at 2:29 PM, Tom Lane <t...@sss.pgh.pa.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
