Apache DataFusion中不同精度小数比较操作的问题分析

在Apache DataFusion项目中，处理不同精度和标度的小数比较时出现了一个有趣的技术问题。这个问题揭示了SQL表达式解析和逻辑计划生成过程中类型处理的复杂性。

问题现象

当用户尝试比较两个不同精度的小数时，DataFusion表现出不同的行为：

1. 直接使用字面量比较时能够正常工作
2. 当其中一个操作数来自表列时则会出现类型不匹配错误

具体表现为：SELECT 1 * 1.000::DECIMAL(4,3) > 1.2::decimal(2,1)可以正常执行，而SELECT a * 1.000::DECIMAL(4,3) > 1.2::decimal(2,1) FROM VALUES (1) AS t(a)则会抛出类型错误。

技术背景

在数据库系统中，DECIMAL类型的处理需要考虑两个关键参数：

• 精度(Precision)：表示数字的总位数
• 标度(Scale)：表示小数点后的位数

当对不同精度/标度的DECIMAL值进行操作时，系统需要进行适当的类型转换和调整，这一过程称为"rebase"。

问题根源

通过代码分析可以发现，问题的核心在于表达式解析和逻辑计划生成的顺序差异：

1. 对于字面量表达式，计算顺序是：

   • 先执行乘法运算
   • 然后进行类型转换和比较

2. 对于涉及列引用的表达式，处理顺序变为：

   • 先生成逻辑计划
   • 在计划生成阶段就尝试类型转换
   • 然后执行乘法运算
   • 乘法运算改变了左操作数的标度
   • 最终导致比较时的类型不匹配

具体来说，处理流程会经过以下关键函数调用链：

1. sql_expr_to_logical_expr
2. binary_op
3. binary
4. binary_numeric_coercion
5. decimal_coercion
6. get_wider_decimal

解决方案思路

要解决这个问题，需要考虑以下几个方面：

1. 表达式的求值顺序：确保在比较前完成所有必要的运算
2. 类型转换时机：推迟类型转换直到所有运算完成
3. 运算对类型的影响：考虑乘法等运算如何影响DECIMAL的精度和标度

一个合理的解决方案可能是在逻辑计划生成阶段保留原始类型信息，在执行阶段再进行最终的类型转换和比较。

技术启示

这个问题展示了SQL查询处理中几个重要的技术点：

1. 表达式求值的惰性特性：并非所有操作都立即执行
2. 类型系统的复杂性：特别是在处理精确数值类型时
3. 逻辑计划与实际执行的差异：计划阶段可能无法预见所有运行时类型变化

对于数据库系统开发者而言，这类问题强调了在类型处理和表达式求值方面需要更加严谨的设计，特别是在处理精确数值运算时。