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?


David Rowley

>                         regards, tom lane

Reply via email to