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
match
