* Theo Schlossnagle ([EMAIL PROTECTED]) 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.
The performance issue you ran into with joins was more likely because
there's no hash function for numeric than the way numerics are stored.
I'm not really sure how I feel about this idea... If it's handled
completely inside numeric then it might be reasonable to do (there
wouldn't *be* any real 'type conversion', numeric would just be modified
to support both sizes and would handle an upgrading/downgrading, I don't
think the code would be all *that* complex, honestly...).
I don't think the indexing would be an issue either as you can provide
the appropriate operations regardless of the size.. It might make
writing the hash function a bit more interesting, but probably not...
We might want to have a compile-time option for this tho, as not all
architectures handle 64bit integer ops very well.
Thanks,
Stephen
signature.asc
Description: Digital signature
