From: Tom Lane <tgl@sss.pgh.pa.us>
To: neverov.max@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17329: Aggregate Functions Precision Error
In-reply-to: <17329-8c3b204b1716bd24@postgresql.org>
References: <17329-8c3b204b1716bd24@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Wed, 08 Dec 2021 21:02:56 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3688942.1638999906.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 08 Dec 2021 16:45:06 -0500
Message-ID: <3688943.1638999906@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3688943.1638999906%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> Aggregate functions (described here
> https://www.postgresql.org/docs/current/functions-aggregate.html#FUNCTIO=
NS-AGGREGATE-STATISTICS-TABLE)
> that are defined for double precision type suffer from loss of
> significance.

This is pretty much inherent in all uses of float arithmetic.
You might be happier using the numeric type (of course, that's
much slower).

Another possibility, for some aggregates, is to order the inputs
in a way that minimizes error accumulation.  For example,

select sum(f1 order by abs(f1)) from ...

I don't know offhand what the best such incantation is for covar_pop;
it might depend on the problem.

			regards, tom lane