Re: BUG #19340: Wrong result from CORR() function

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> Looking at float8_regr_accum(), I think it would be preferable to
> arrange for it to leave Sxx, Syy, and Sxy zero until distinct X and Y
> values are seen. I.e., something like this:

That seems like a good idea. I was initially worried that the extra
isnan() checks would slow down aggregation noticeably in the normal
case where we soon discover that the inputs aren't all equal. They
don't seem to though. For me, the attached v2 clocks in at only 0.9%
slower than HEAD, IOW actually faster than v1; which I suspect just
proves that what we're trying to measure here is comparable to the
noise threshold.

I took your other suggestions too, except for:

> I also wonder if it would be worth doing something similar for the
> single-variable aggregates so that var_pop(), var_samp(),
> stddev_pop(), and stddev_samp() would all return exactly zero, and
> avg() would return the exact common value, if all the inputs were
> constant.

I'm less excited about this, because for all those aggregates,
you have the option of using the numeric variant if you're
dissatisified with the accuracy of the float8 variant. Also,
given that the per-input work is substantially less, the overhead
of tracking the common input value would probably be noticeably
greater. If somebody else wants to investigate that, I won't
stand in the way, but I don't want to do it.

regards, tom lane