Theo Schlossnagle <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
