Re: [HACKERS] Re: bug on aggregate function AVG()

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Sferacarta Software <sferac(at)bo(dot)nettuno(dot)it>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: bug on aggregate function AVG()
Date: 1998-11-05 16:00:46
Message-ID: 3641CBAE.286F1A7D@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-11-05 16:25:18 Re: [HACKERS] int8 size
Previous Message Tom Lane 1998-11-05 15:13:42 Re: [HACKERS] Open the flood gates...v6.4 is tag'd...