On Sun, Dec 15, 2013 at 3:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> I wrote: > > It's not so good with two-row windows though: > > Actually, carrying that example a bit further makes the point even more > forcefully: > > Table correct sum of negative-transition > this + next value result > 1e20 1e20 1e20 + 1 = 1e20 > 1 1 1e20 - 1e20 + 0 = 0 > 0 0 0 - 1 + 0 = -1 > 0 1 -1 - 0 + 1 = 0 > 1 > > Those last few answers are completely corrupt. > > I guess the answer for the people that complain about slowness could be that they create their own aggregate function which implements float4pl as the trans function and float4mi as the negative trans function. They can call it SUMFASTBUTWRONG() if they like. Perhaps it would be worth a note in the documents for this patch? I've removed the negative trans function setups for float4 and float8 with SUM and AVG stuff in my working copy now. As for numeric, I did start working on this just after I posted the original patch and before I saw your comment about it. I did end up making do_numeric_desperse() which was to be the reverse of do_numeric_accum(), but I got stuck on the equivalent of when do_numeric_accum() does mul_var(&X, &X, &X2, X.dscale * 2); If it is decided that we don't want to implement a negative trans function for numeric, then I guess I could leave in my trans function to allow users to create their own fast version, maybe? Regards David Rowley > regards, tom lane >
