From: | wieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | lockhart(at)alumni(dot)caltech(dot)edu (Thomas Lockhart) |
Cc: | jwieck(at)debis(dot)com, hook(at)aktrad(dot)ru, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] 6.5.0 - Overflow bug in AVG( ) |
Date: | 1999-06-16 23:20:23 |
Message-ID: | m10uOyl-0003kLC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart wrote:
>
> > > Of course. These are integer fields? I've been considering changing
> > > all accumulators (and results) for integer aggregate functions to
> > > float8, but have not done so yet. I was sort of waiting for a v7.0
> > > release, but am not sure why...
> >
> > Wouldn't it be better to use NUMERIC for the avg(int) state
> > values? It will never loose any significant digit.
>
> Sure. It would be fast, right? avg(int) is likely to be used a lot,
> and should be as fast as possible.
I think it would be fast enough, even if I have things in
mind how to speed it up. But that would result in a total
rewrite of NUMERIC from scratch.
The only math function of NUMERIC which is time critical for
AVG() is ADD. And even for int8 the number of digits it has
to perform is relatively small. I expect the time spent on
that is negligible compared to the heap scanning required to
get all the values.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Henry B. Hotz | 1999-06-16 23:25:15 | Re: [HACKERS] Postgres mailing lists |
Previous Message | Tom Lane | 1999-06-16 23:02:05 | Apparent bug in _make_subplan |