On Sep 16, 2006, at 7:31 PM, Gregory Stark wrote:
Would that pose indexing issues? It would also mean that when
tables you'd have to handle some interesting type conversion
times). We had someone accidentally create a largish table with
"numeric" and other tables are "bigint", it was disastrous for
(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
of data types grows but it works.
In any case I think Jim was suggesting this be handled internally
numeric data type which wouldn't cause this problem. However I'm
anything has to be done. A numeric is an array of 16 bit integers,
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
Well, just an integer plus a useless exponent. I think it would be
trick to normalize the exponent to the end of the last element of
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