Re: more numeric stuff - Mailing list pgsql-hackers

From Robert Haas
Subject Re: more numeric stuff
Date
Msg-id AANLkTikLor9jBWj7Pq1C189_dnv95TMfCddHaaXMjA3u@mail.gmail.com
Whole thread Raw
In response to Re: more numeric stuff  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Aug 13, 2010 at 1:10 PM, Bruce Momjian <bruce@momjian.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: patch: General purpose utility functions used by the JSON data type
Next
From: Alvaro Herrera
Date:
Subject: Re: patch: utf8_to_unicode (trivial)