Re: [PATCH] Negative Transition Aggregate Functions (WIP) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Date
Msg-id 21468.1387069230@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Negative Transition Aggregate Functions (WIP)  (Greg Stark <stark@mit.edu>)
Responses Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Re: [PATCH] Negative Transition Aggregate Functions (WIP)
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> On 14 Dec 2013 15:40, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>> 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.

Well, we can't easily do better than the old answers, and the new ones
might be arbitrarily worse.  Example: sum or average across single-row
windows ought to be exact in any case, but it might be arbitrarily wrong
with the negative-transition technique.

More generally, this is supposed to be a performance enhancement only;
it's not supposed to change the results.

This consideration also makes me question whether we should apply the
method for NUMERIC.  Although in principle numeric addition/subtraction
is exact, such a sequence could leave us with a different dscale than
is returned by the existing code.  I'm not sure if changing the number of
trailing zeroes is a big enough behavior change to draw complaints.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ruleutils vs. empty targetlists
Next
From: Josh Berkus
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)