Re: Decimal64 and Decimal128

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Feng Tian <ftian(at)vitessedata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Decimal64 and Decimal128
Date: 2017-06-17 19:50:55
Message-ID: CAEepm=2-xj--UgWOALizfN3rYMiywhYkP3d24A5k6O4kfU-9_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 18, 2017 at 5:38 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Jun 15, 2017 at 10:27 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> 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.
>
> I feel like these would logically just be different types, like int4
> and int8 are. We don't have integer(9) and integer(18).

Hmm. Perhaps format_type.c could render decfloat16 as decfloat(16)
and decfloat34 as decfloat(34), and gram.y could have a production
that selects the right one when you write DECFLOAT(x) and rejects
values of x other than 16 and 34.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-06-17 19:55:11 Re: Preliminary results for proposed new pgindent implementation
Previous Message Tom Lane 2017-06-17 19:13:43 Re: Preliminary results for proposed new pgindent implementation