<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 15, 2013 at 12:48 PM, Greg Stark <span
dir="ltr"><<ahref="mailto:stark@mit.edu" target="_blank">stark@mit.edu</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div
class="h5"><pdir="ltr"><br /> On 14 Dec 2013 15:40, "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us"
target="_blank">tgl@sss.pgh.pa.us</a>>wrote:<br /> ><br /> > David Rowley <<a
href="mailto:dgrowleyml@gmail.com"target="_blank">dgrowleyml@gmail.com</a>> writes:<br /> > > The attached
patchis not quite finished yet, I've not yet fully covered<br /> > > SUM and AVG for all types.<br /> ><br />
>I think you *can't* cover them for the float types; roundoff error<br /> > would mean you don't get the same
answersas before.<br /></div></div><p dir="ltr">I was going to say the same thing. But then I started to wonder....
What'sso special about the answers we used to give? They are also subject to round off and the results are already
quitequestionable in those cases.</blockquote></div>I guess they probably shouldn't be, subject to rounding /
influencedby errors from tuples that are out of scope of the aggregate context.</div><div class="gmail_extra">Though
sayingthat it would be a shame to have this optimisation for all but float and double. I can imagine the questions in
[GENERAL]..Why is SUM(<int>) OVER ().. fast but SUM(<float>) OVER () slow? I wonder what other RDBMS' do
here...</div><divclass="gmail_extra"><br /></div><div class="gmail_extra">Regards</div><div class="gmail_extra"><br
/></div><divclass="gmail_extra">David Rowley</div></div>