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 3641CBAE.286F1A7D@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] Re: bug on aggregate function AVG()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Is there any reason for not use these functions on SUM() and AVG() on
> official release ?

It sounds like a good idea. The only hesitation I have at the moment is
that not all platforms have int8 support, and I'm not certain which
these are. Also, accumulating int4 into int8 is probably pretty slow
since on 32-bit machines the "long long" is usually done in a s/w
library, not in machine code.

float8 might be a better choice for accumulating AVG(), but I'm worried
about incorrect results with large tables (> 1M entries) which have
pathological distributions of numbers (e.g. 1M entries with MAXINT and
1M entries with zero). int4 gives ~9.2 decimal places, float8 gives ~15
decimal places, so there is only about ~6 decimal places of headroom.

Of course, why am I worried? That is much better than what we have
currently. And someone reported that at least one commercial system
(Sybase?) returns float8 for avg() (and sum()?) as I recall.

So, your suggestion is that for AVG() at least we return something other
than the input type; how about returning float8 for any input type?
Don't know if SUM() could/should behave similarly...
                      - Tom


pgsql-hackers by date:

Previous
From: Sferacarta Software
Date:
Subject: int8 size
Next
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] int8 size