From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: more numeric stuff |
Date: | 2010-08-13 17:35:04 |
Message-ID: | AANLkTikLor9jBWj7Pq1C189_dnv95TMfCddHaaXMjA3u@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 13, 2010 at 1:10 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Tom Lane wrote:
>> > 3. 64-bit arithmetic. Right now, mul_var() and div_var() use int for
>> > arithmetic, but haven't we given up on supporting platforms without
>> > long long? I'm not sure I'm motivated enough to write the patch
>> > myself, but it seems like 64-bit arithmetic would give us a lot more
>> > room to postpone carries.
>>
>> I don't think this would win unless we went to 32-bit NumericDigit,
>> which is a problem from the on-disk-compatibility standpoint, not to
>> mention making the alignment issues even worse. Postponing carries is
>> good, but we have enough headroom for that already --- I really doubt
>> that making the array elements wider would save anything noticeable
>> unless you increase NBASE.
>
> Should we be collecting pg_upgrade-breaking changes on the TODO list so
> we can implement them in one future release?
Possibly, but I don't think we want to do this one even if we WERE
willing to break pg_upgrade. Increasing NBASE would be a complete
disaster in terms of Numeric on-disk footprint, which - even with the
changes I just implemented - is already uncomfortably high.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-08-13 17:40:12 | Re: patch: utf8_to_unicode (trivial) |
Previous Message | Robert Haas | 2010-08-13 17:33:06 | Re: patch: General purpose utility functions used by the JSON data type |