Re: Decimal64 and Decimal128

On Fri, Jun 16, 2017 at 1:24 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 16 June 2017 at 05:42, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> Bumping this ancient thread to say that DECFLOAT appears to have
>> landed in the SQL standard. I haven't looked at SQL:2016 myself by I
>> just saw this on Markus Winand's Modern SQL blog:
>>
>> "There is a new type decfloat[(<precision>)] (T076)."
>>
>> http://modern-sql.com/blog/2017-06/whats-new-in-sql-2016
>>
>> So far it's supported only by DB2 (inventor) and FirebirdSQL has just
>> announced support in the next release.
>
> I was pretty excited by decimal floating point initially, but the lack
> of support for its use in hardware in commonplace CPUs makes me less
> thrilled. IIRC Intel was talking about adding it, but I can't find any
> references to that anymore. POWER6 and POWER7 has it, which is great,
> but hardly justifies a push for getting it into the core Pg.
>
> Some of the discussion on
> https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library?page=1
> suggests that doing it fully in hardware is very expensive, so a mixed
> software/microcode implementation with some hardware assistance is
> likely if/when it comes.

There are considerations other than raw arithmetic performance though:

1. They are fixed size, and DECFLOAT(9) [= 32 bit] and DECFLOAT(17)
[= 64 bit] could in theory be passed by value. Of course we don't
have a way to make those pass-by-value and yet pass DECFLOAT(34) [=
128 bit] by reference! That is where I got stuck last time I was
interested in this subject, because that seems like the place where we
would stand to gain a bunch of performance, and yet the limited
technical factors seems to be very well baked into Postgres.

2. They may be increasingly used as 'vocabulary' datatypes as more
languages and databases adopt them. That's probably not a huge
semantic problem since DECIMAL can represent most useful DECFLOAT
values exactly (but not some IEEE 754 quirks like -0, -inf, +inf, NaN,
and I haven't checked what SQL:2016 says about that anyway but if it's
based directly on IEEE 754:2008 then I guess they'll be in there).

I don't understand these things but it looks like the support in C
(originally proposed as N1312 and implemented by IBM, HP, GCC and
Intel compilers) has reached the next stage and been published as
ISO/IEC TS 18661-2:2015, and now N2079 proposes that TS 18661-2 be
absorbed into C2x (!). As glacial as ISO processes may be, it's
encouraging that there is now a TS even though I'm not allowed to
download it without paying CHF178. Meanwhile Python and others just
did it (albeit vastly less efficiently).

--
Thomas Munro
http://www.enterprisedb.com