On Fri, Aug 13, 2010 at 1:10 PM, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
