Re: [HACKERS] Re: bug on aggregate function AVG()
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Re: bug on aggregate function AVG() |
Дата | |
Msg-id | 3641CBAE.286F1A7D@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: bug on aggregate function AVG() (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: