On Sep 16, 2006, at 7:31 PM, Gregory Stark wrote:
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.

Yes, I definitely meant for this to be internal-only... end users shouldn't notice any difference (except hopefully improved performance).

If all the math is done in 64k chunks then this might not be as big a help. Numbers between 2^16 and 2^64 (or 2^32 on some platforms) would probably be faster, but how much faster isn't clear. Perhaps the OP could do some testing if someone came up with a quick and dirty prototype patch.

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.

How would that help? If I'm understanding correctly you're just talking about storing how many places after the decimal instead of how many in front of it?
Jim Nasby                                            [EMAIL PROTECTED]
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to