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 по дате отправления:

Предыдущее
От: Sferacarta Software
Дата:
Сообщение: int8 size
Следующее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [HACKERS] int8 size