Re: [PATCH] Negative Transition Aggregate Functions (WIP)

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Date: 2013-12-15 00:08:42
Message-ID: CAApHDvoXMAUrKrvVZiMq-yCiX-zLYAPa7D+f9OC=MizEc2vGqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 15, 2013 at 12:48 PM, Greg Stark <stark(at)mit(dot)edu> wrote:

>
> On 14 Dec 2013 15:40, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > > The attached patch is not quite finished yet, I've not yet fully
> covered
> > > SUM and AVG for all types.
> >
> > I think you *can't* cover them for the float types; roundoff error
> > would mean you don't get the same answers as before.
>
> I was going to say the same thing. But then I started to wonder.... What's
> so special about the answers we used to give? They are also subject to
> round off and the results are already quite questionable in those cases.
>
I guess they probably shouldn't be, subject to rounding / influenced by
errors from tuples that are out of scope of the aggregate context.
Though saying that 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...

Regards

David Rowley

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-12-15 00:20:27 Re: ruleutils vs. empty targetlists
Previous Message Greg Stark 2013-12-14 23:48:04 Re: [PATCH] Negative Transition Aggregate Functions (WIP)