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? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
