Added fix for div and mod functions in columnstore - MCOL-4601 #3852
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description: The MOD and DIV operators in MariaDB ColumnStore were not behaving consistently with InnoDB (the standard MariaDB storage engine), leading to incorrect results, particularly with floating-point or DECIMAL types.
Analysis and Root Cause
The MOD operator was failing because the implementation in Func_mod::getDecimalVal only considered the first parameter (parm[0]) for the precision calculation and failed to use the second parameter (parm[1]) at all. This resulted in wrong precision and consequently, an incorrect remainder calculation.
Fix Summary
The fix ensures that:
Verification result:
Analysis and Root Cause
The primary issue in the Func_div::getIntVal function was the reliance on the double data type. The function used getDoubleVal to retrieve operands, forcing any high-precision DECIMAL data into the lossy binary floating-point format. This resulted in an inexact quotient that, when cast to int64_t, produced an incorrect integer result due to the inherent loss of precision.
Fix Summary
To ensure mathematically exact results for integer division, the fix replaces all reliance on floating-point arithmetic with the native high-precision decimal type:
Verification result: