Ingnored integer overflow
Hi, according to documentation: Add, subtract, and multiply operations ignore overflow. In our application built on Vertica we use several CREATE TABLE AS SELECT statements depending on each other so possible overflow error might leak through unnoticed, giving incorrect results in the end. Are there any plans that Vertica in some future version will throw an error in these situations instead of ignoring them? We might come into this (although rarely) with integer arithmetic so one obvious workaround is to use some other type with greater range, e.g. float. What are the drawbacks of this solution in terms of storage requirements and query performance?
+2Hi David,
I'm not personally aware of any official plans either way regarding overflow errors. I'm also not the best person to ask. Our sales and support channels can get you better information about future plans.
Regarding workarounds, your alternative data types include floats and numerics. In terms of storage requirements, well, it depends. Floats are also a 64-bit type, so their uncompressed footprint is the same; they may compress differently, though, depending on what your data looks like. Numerics are larger (there is some overhead since they are variable-size) but, again, compression is hard to predict. In both cases, I would expect to see some slowdown; probably more with Numerics because they're a full arbitrary-precision type; but this too can vary hugely based on the particular queries that you are running and on what your data looks like.
So, really, the only reasonably-accurate answer is "try it!"
Adam
I'm not personally aware of any official plans either way regarding overflow errors. I'm also not the best person to ask. Our sales and support channels can get you better information about future plans.
Regarding workarounds, your alternative data types include floats and numerics. In terms of storage requirements, well, it depends. Floats are also a 64-bit type, so their uncompressed footprint is the same; they may compress differently, though, depending on what your data looks like. Numerics are larger (there is some overhead since they are variable-size) but, again, compression is hard to predict. In both cases, I would expect to see some slowdown; probably more with Numerics because they're a full arbitrary-precision type; but this too can vary hugely based on the particular queries that you are running and on what your data looks like.
So, really, the only reasonably-accurate answer is "try it!"
Adam
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
