Re: Adding IEEE 754:2008 decimal floating point and hardware support for it

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding IEEE 754:2008 decimal floating point and hardware support for it
Date: 2013-06-25 00:31:15
Message-ID: 51C8E4D3.4020709@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12.6.2013 07:03, Pavel Stehule wrote:
> Hello
>
> I worked with gdc' _Decimal* types last week
>
> https://github.com/okbob/pgDecimal
>
> I tested it, and should to say, so implementation in gcc is not good
> - lack of lot of functionality, and our Money type is little bit
> faster :( Tomas Vondra play with own implementation, but I don't know
> any performance results.

For the record, my intent was not to implement IEEE-compatible data
type, but rather improving performance of two "issues" we face with the
NUMERIC data type - storage requirements and aggregates, by introducing
a specialized numeric data type based on INT/BIGINT.

I've been thinking about the common workaround - storing "normalized"
values in INT or BIGINT columns - for example number of cents instead of
amount in dolars (e.g. 12050 = $120.50) and so on. I've made this easier
by keeping the scale within the value itself (which resembles a bit what
IEEE does with DECIMALnn data types).

The current experimental implementation is available at

https://github.com/tvondra/fixed_numeric

so feel free to comment. It imposes some additional restrictions, that
may not be entirely necessary - most importantly the added or subtracted
values need to share the scale (so for example "1.01 + 1.11" works but
"1.01 + 1.2" does not). This restriction is not necessary, and while it
makes the implementation easier (and works quite well when aggregating
values stored in a table, as they share the scale), it shouldn't be
difficult to remove it.

Right now I'm considering whether to keep the multiplication and
division implementations - this is the main weak point of the current
code, as these operations do not preserve scale (unlike plus and minus).
I'm seriously considering getting rid of these operations and handling
them by an implicit cast to plain NUMERIC. Well, it's not going to be
fast but I do care about AVG/SUM/MIN/MAX more.

kind regards
Toms

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Kupershmidt 2013-06-25 00:34:43 Re: pg_filedump 9.3: checksums (and a few other fixes)
Previous Message Claudio Freire 2013-06-25 00:21:26 Re: C++ compiler