I have a series of calculation times in a DB2 SQL DB that are stored as float with a default value of 0.0.
The table being updated is as follows:
CREATE TABLE MY_CALC_DATA_TABLE
(
CALCDATE TIMESTAMP,
INDIV_CALC_DURATION_IN_S FLOAT WITH DEFAULT 0.0,
CALC_TIME_PERCENTAGE FLOAT WITH DEFAULT 0.0
)
Using a sproc. I am calculating the sum as follows:
CREATE OR REPLACE PROCEDURE MY_SCHEMA.MY_SPROC (IN P_DATE TIMESTAMP)
LANGUAGE SQL
NO EXTERNAL ACTION
BEGIN
DECLARE V_TOTAL_CALC_TIME_IN_S FLOAT DEFAULT 0.0;
-- other stuff setting up and joining data
-- Calculate the total time taken to perform the
-- individual calculations
SET V_TOTAL_CALC_TIME_IN_S =
(
SELECT
SUM(C.INDIV_CALC_DURATION_IN_S)
FROM
MY_SCHEMA.MY_CALC_DATA_TABLE C
WHERE
C.CALCDATE = P_DATE
)
-- Now calculate each individual calculation's percentage
-- of the toal time.
UPDATE
MY_SCHEMA.MY_CALC_DATA_TABLE C
SET
C.CALC_TIME_PERCENTAGE =
(C.INDIV_CALC_DURATION_IN_S / V_TOTAL_CALC_TIME_IN_S) * 100
WHERE
C.CALCDATE = P_DATE;
END@
Trouble is, when I do a sum of all the CALC_TIME_PERCENTAGE values for the specified CALC_DATE it is always less than 100% with the sum being values like 80% or 70% for different CALC_DATES.
We are talking between 35k and 55k calculations here with the maximum individual calculation’s percentage of the total, as calculated above, being 11% and lots of calculations in the 0.00000N% range.
To calculate the total percentage I am using the simple query:
SELECT
SUM(C.CALC_TIME_PERCENTAGE)
FROM
MY_SCHEMA.MY_CALC_DATA_TABLE C
WHERE
C.CALCDATE = P_DATE;
Any suggestions?
Update: Rearranging the calc. as suggested fixed the problem. Thanks. BTW In DB2 FLOAT and DOUBLE are the same type. And now to read that suggested paper on floats.
If the field
C.INDIV_CALC_DURATION_IN_Swere Integer, I would assume it’s a rounding error. Reading again, that is not the problem as the datatype isFLOAT.You can still try using this. I wouldn’t be surprised if this yielded (slighly) different results than the previous method:
But you mention that there a lot of rows in a calculation for a certain date, so it may be a rounding error due to that. Try with
DOUBLEdatatype in both fields (or at least theCALC_TIME_PERCENTAGEfield) and see if the difference from100%gets smaller.I’m not sure if
DB2hasDECIMAL(x,y)datatype. It may be more appropriate in this case.Another problem is how you find the sum of
CALC_TIME_PERCENTAGE. I suppose you (and everyone else) would use the:This way, you have no way to determine in what order the summation will be done. It may not be even possible to determine that but you can try:
The optimizer may disregard the interior
ORDER BYbut it’s worth a shot.Another possibility for this big difference is that rows are deleted from the table between the
UPDATEand theSHOW percent SUMoperations.You can test if that happens by running the calculations (without UPDATE) and summing up: