Re: Adding IEEE 754:2008 decimal floating point and hardware support for it
От | Tomas Vondra |
---|---|
Тема | Re: Adding IEEE 754:2008 decimal floating point and hardware support for it |
Дата | |
Msg-id | 51C8E4D3.4020709@fuzzy.cz обсуждение исходный текст |
Ответ на | Re: Adding IEEE 754:2008 decimal floating point and hardware support for it (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: