Theo Schlossnagle <jesus@omniti.com> writes:
> Would that pose indexing issues? It would also mean that when joining two
> tables you'd have to handle some interesting type conversion issues (at
> times). We had someone accidentally create a largish table with userid as
> "numeric" and other tables are "bigint", it was disastrous for performance
> (joining). I'd imagine that if the above wasn't done cleverly, that
> performance problem would be repeated.
That used to be a problem but Tom solved it a little while back. Not a perfect
solution in that it requires lots of cross-data-type operators as the number
of data types grows but it works.
In any case I think Jim was suggesting this be handled internally to the
numeric data type which wouldn't cause this problem. However I'm not sure
anything has to be done. A numeric is an array of 16 bit integers, so anything
under 64k *is* stored just as an integer.
Well, just an integer plus a useless exponent. I think it would be a neat
trick to normalize the exponent to the end of the last element of the mantissa
rather than the first digit so that integers don't need an exponent.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com