Re: more numeric stuff

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

In response to

Browse pgsql-hackers by date

  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