Re: [HACKERS] Re: bug on aggregate function AVG() - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] Re: bug on aggregate function AVG()
Date
Msg-id 36406FCC.8C3B9F32@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] Re: bug on aggregate function AVG()  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
Responses Re: [HACKERS] Re: bug on aggregate function AVG()
List pgsql-hackers
> I don't know what does the word "hosed" mean Tom, I hope you don't 
> want to tell me there's no solution for this problem.

As you guessed, "hosed" isn't good ;)

> I see that AVG() and SUM() uses an accumulator not enough big to hold
> the result of calculation, but the point is: should we consider this
> thing a "terrible" bug or an acceptable feature ?
> What about to convert every accumulator to float8 ?

imho we can't do that because we lose the exact qualities of integers.
If you accumulate in float8, and if you take a sum over a very large
table, you might start ignoring values. That is, if you have accumulated
15 or 16 digits worth of number, and then try adding 1 as the next
number, the result will be the same as the input. With integers that is
never the case, but we have to deal with overflows better.

I would think we should start signalling overflows rather than silently
overflowing, but I'm not sure what that entails.

> Anyway I think we need to work a little bit on aggregates:
> MIN() and MAX() doesn't accept a string as parameter.

Yes, at the moment only numeric quantities are supported.

> SUM() and AVG() gives a wrong result because it goes on overflow.
> and none of them allows the clause DISTINCT.

Yes, SELECT SUM(DISTINCT i) FROM t; is not yet supported. That's a
project for v6.5.

btw, I'm also planning on working on your "NULL problem" you mentioned
earlier...
                   - Tom


pgsql-hackers by date:

Previous
From: A James Lewis
Date:
Subject: Re: [HACKERS] Warning!!
Next
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] Warning!!