Greetings,
Environment:
Zabbix 2.0.3
Debian Squeeze and Ubuntu Precise
64 bits and 32 bits OSs
PostgreSQL 8.4
First: I know we need to discuss for other options for this, as the attached patch is far from perfect, and will lose precision of stored value under certain conditions. This was made mainly to fix an immediate problem I was having. I understand where your 12.4 came from (999999999999.9999 is the maximum that will get into "double" without serious rounding issues).
Also, sorry if this is not the correct forum for this.
A few days ago, we were working on some items with big values (like: 1549500635179), initially, I used Numeric (unsigned), that worked at first, until we decided to calculate some "deltas" for the data, sometimes, the data would reduce its value, thus producing a negative delta, that would show up as a large integer (of course, it is unsigned). Well, I changed the Calculated item type to Numeric (float), but it would still produce a large integer instead of expected negative number (likely, calculations are made unsigned in Zabbix code), so, I had to change all items to Numeric (float), and the calculation now produced expected negative numbers.
Now, after I changed all items to "Numeric (float)", I got hit by a limitation on the range for "Numeric (float)" for some items (leading to "Not supported" items), upon checking DB schema and code, I found it was:
numeric(16,4) <--- PostgreSQL
double(16,4) <---- MySQL
decfloat(16) <--- DB2 (doesn't needs fix)
number(20,4) <--- Oracle (doesn't needs fix)
double(16,4) <--- SQLite
Now, this implies, at least for PostgreSQL and MySQL, that the actual limit is 12 digits, and then 4 more after the decimal point. As you can see, the number I was receiving, 1549500635179, has 13 digits.
So, after looking around, I decided I would go ahead and change this (attached patch, that, I know, is far from ideal, and just wanted to share). I decided to increase the number of digits to 15, and on the DB, still allow for 4 decimal places (that, if used in full, will cause rounding issues on Zabbix server code, that uses "double" variables).
Now, I think there are other (better) options for this, including:
+ Signed (vs unsigned) integer numeric types for Zabbix. I think this would just solve the problem, as would allow for calculations using Numeric data types (not float), even if the calculation result is negative.
+ Make sure all calculations are made using double or long double (yes, even the ones done between integer items), this would allow to have integer items, but still have calculations that return floating point (rate between two items, itemA/itemB). Maybe, make sure the calculation uses *destination* type on all the operations.
+ Uses arbitrary precision library for Zabbix, like GMP.
What do you think?
Sincerely,
Ildefonso Camargo
Environment:
Zabbix 2.0.3
Debian Squeeze and Ubuntu Precise
64 bits and 32 bits OSs
PostgreSQL 8.4
First: I know we need to discuss for other options for this, as the attached patch is far from perfect, and will lose precision of stored value under certain conditions. This was made mainly to fix an immediate problem I was having. I understand where your 12.4 came from (999999999999.9999 is the maximum that will get into "double" without serious rounding issues).
Also, sorry if this is not the correct forum for this.
A few days ago, we were working on some items with big values (like: 1549500635179), initially, I used Numeric (unsigned), that worked at first, until we decided to calculate some "deltas" for the data, sometimes, the data would reduce its value, thus producing a negative delta, that would show up as a large integer (of course, it is unsigned). Well, I changed the Calculated item type to Numeric (float), but it would still produce a large integer instead of expected negative number (likely, calculations are made unsigned in Zabbix code), so, I had to change all items to Numeric (float), and the calculation now produced expected negative numbers.
Now, after I changed all items to "Numeric (float)", I got hit by a limitation on the range for "Numeric (float)" for some items (leading to "Not supported" items), upon checking DB schema and code, I found it was:
numeric(16,4) <--- PostgreSQL
double(16,4) <---- MySQL
decfloat(16) <--- DB2 (doesn't needs fix)
number(20,4) <--- Oracle (doesn't needs fix)
double(16,4) <--- SQLite
Now, this implies, at least for PostgreSQL and MySQL, that the actual limit is 12 digits, and then 4 more after the decimal point. As you can see, the number I was receiving, 1549500635179, has 13 digits.
So, after looking around, I decided I would go ahead and change this (attached patch, that, I know, is far from ideal, and just wanted to share). I decided to increase the number of digits to 15, and on the DB, still allow for 4 decimal places (that, if used in full, will cause rounding issues on Zabbix server code, that uses "double" variables).
Now, I think there are other (better) options for this, including:
+ Signed (vs unsigned) integer numeric types for Zabbix. I think this would just solve the problem, as would allow for calculations using Numeric data types (not float), even if the calculation result is negative.
+ Make sure all calculations are made using double or long double (yes, even the ones done between integer items), this would allow to have integer items, but still have calculations that return floating point (rate between two items, itemA/itemB). Maybe, make sure the calculation uses *destination* type on all the operations.
+ Uses arbitrary precision library for Zabbix, like GMP.
What do you think?
Sincerely,
Ildefonso Camargo
Comment