DuckDB中空表过滤下推问题的技术分析

在DuckDB数据库系统中，我们发现了一个关于空表过滤下推的有趣技术问题。这个问题出现在使用JSON函数结合动态列名进行数据过滤的场景中。

问题现象

用户尝试使用动态JSON过滤条件对测试表进行查询。测试表包含简单的两列数据：(a,b)值为(1,2)、(2,3)、(3,1)、(1,2)、(2,3)、(2,4)和(3,2)。查询的目的是找出那些a和b值同时出现在JSON变量W中的记录。

当这个过滤条件放在SELECT子句中时，表达式计算正确；但一旦移到WHERE子句中，查询就返回空表结果。有趣的是，即使用NOT取反这个表达式，结果仍然是空表。只有禁用过滤下推优化器(SET disabled_optimizers = 'filter_pushdown')后，查询才能返回预期结果。

技术背景

这个问题涉及到DuckDB的几个关键技术点：

1. 过滤下推优化：DuckDB会尝试将过滤条件尽可能下推到查询计划的最底层，以减少需要处理的数据量。

2. JSON函数处理：查询中使用了getvariable、json_keys和json_contains等JSON处理函数。

3. 动态列引用：通过columns()函数动态引用列名。

问题本质

问题的核心在于过滤下推优化器在处理包含动态列引用的复杂JSON表达式时出现了逻辑错误。优化器可能过早地评估了表达式，而没有正确考虑运行时才能确定的列值。

具体来说，表达式(getvariable('W') -> '/'||alias(columns(getvariable('W').json_keys()))).json_contains(columns(getvariable('W').json_keys()))需要在运行时才能完全解析，但过滤下推优化器尝试在优化阶段就确定其结果。

解决方案

目前有两种可行的解决方案：

1. 临时解决方案：禁用过滤下推优化器，如用户发现的SET disabled_optimizers = 'filter_pushdown'。

2. 永久修复：需要修改DuckDB的优化器逻辑，使其能够正确处理这种包含动态列引用的复杂JSON表达式。这包括确保这类表达式不会被过早评估，或者在优化阶段能够正确模拟其运行时行为。

技术建议

对于开发者遇到类似问题时，建议：

1. 对于包含动态列引用或复杂JSON处理的查询，可以先尝试禁用特定优化器来验证是否是优化器导致的问题。

2. 考虑将复杂的过滤条件重构为更简单的形式，或者使用子查询隔离复杂逻辑。

3. 关注DuckDB的更新，因为这类问题通常会在后续版本中得到修复。

这个问题展示了数据库优化器在处理现代复杂查询时面临的挑战，特别是在动态SQL和半结构化数据处理日益普及的背景下。