Re: [HACKERS] Sum aggregate calculation for single precsion real - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Sum aggregate calculation for single precsion real
Date
Msg-id CA+TgmoaL8mPBRes=5WnwhQebCmwCjw7avrx0eWgWfLF1CC+EKw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Sum aggregate calculation for single precsion real  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: [HACKERS] Sum aggregate calculation for single precsion real  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Feb 14, 2017 at 8:59 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> From my point of your it is strange and wrong expectation.
>> I am choosing "float4" type for a column just because it is enough to
>> represent range of data I have and I need to minimize size of record.
>
> In other words, you've decided to trade accuracy for performance...
>
>> But when I am calculating sum, I expect to receive more or less precise
>> result. Certainly I realize that even in case of using double it is
>
> ... but now you want to trade performance for accuracy? Why would you expect
> the database to magically come to that conclusion?

Well put.  Although it's worth noting that we aren't 100% consistent
about this stuff: sum(smallint), sum(integer), and sum(bigint) all use
an output data type different from the input data type, but other
versions of sum() don't.  To some extent all of these decisions are
just guesses about what users will find useful, and as this thread
shows, not everybody's going to agree.  But I don't think our guesses
are flagrantly unreasonable or anything.

There's also nothing to prevent Konstantin or anybody else who doesn't
like the default behavior to create their own version of sum(float4)
and put it in a schema that's listed before pg_catalog in search_path.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: [HACKERS] operator_precedence_warning vs make installcheck
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Documentation improvements for partitioning