On Thu, Dec 18, 2014 at 10:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Tom> If you're concerned about arithmetic performance, there is a
>> Tom> very obvious fix here: use double.
>
>> Independently of this specific example, the obvious issue there is that
>> there are applications for which double is simply not acceptable.
>
> As the guy who last fooled with the numeric calculation algorithms in any
> major way, I'm painfully aware that numeric is not necessarily more
> accurate than double for anything more complicated than
> addition/subtraction/multiplication. The example that was shown upthread
> is pretty nearly a textbook case of something where I'd not believe that
> numeric offers any accuracy improvement without *very* careful
> investigation. In general, if your application is sufficiently
> arithmetic-intensive that you need to care about the speed of calculations,
> then it's not obvious which one to pick, and if I hear a knee-jerk "simply
> not acceptable" I'm simply going to conclude that you haven't actually
> studied the subject.
I think that's ridiculous. You're basically arguing that numeric
doesn't offer meaningful advantages over float8, which flies in the
face of the fact that essentially every database application I've ever
seen uses numeric and I'm not sure I've ever seen one using float8.
Nearly all database users prefer to store quantities like currency
units in a type that is guaranteed not to lose precision.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
