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 jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)