Re: [HACKERS] Decimal64 and Decimal128
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Decimal64 and Decimal128 |
Дата | |
Msg-id | CA+TgmobTYjrZNQZtrpBpgAZ_RMXFkdZZrOMnWJhJ7SMcXXbxyQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Decimal64 and Decimal128 (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: [HACKERS] Decimal64 and Decimal128
|
Список | pgsql-hackers |
On Sat, Jun 17, 2017 at 3:50 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Sun, Jun 18, 2017 at 5:38 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Thu, Jun 15, 2017 at 10:27 PM, Thomas Munro >> <thomas.munro@enterprisedb.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. What would be the point of that? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: