GreptimeDB 0.12版本CTE查询中GROUP BY支持问题分析

在GreptimeDB时序数据库的最新版本0.12中，用户报告了一个关于公共表表达式(CTE)查询中GROUP BY子句支持的问题。这个问题表现为当用户尝试在CTE查询中使用GROUP BY时，系统会抛出内部错误，而在之前的0.11.3版本中相同的查询可以正常执行。

问题复现步骤显示，用户创建了一个名为grpc_latencies的表，包含时间戳、主机名和延迟三个字段。然后尝试通过CTE查询计算每2秒窗口内各主机的平均延迟，再对这些结果按时间戳分组计算全局平均值。在0.11.3版本中，这个查询能够正确返回结果，但在0.12版本中却导致了DataFusion引擎的内部错误。

技术分析表明，这个问题的根源在于DataFusion查询引擎的物理计划与逻辑计划之间的模式(schema)验证机制。具体来说，DataFusion在0.12版本中引入了一个更严格的模式检查机制，要求物理输入模式必须与从逻辑输入模式转换而来的模式完全一致。当这种一致性检查失败时，系统就会抛出"Physical input schema should be the same as the one converted from logical input schema"的错误。

开发团队迅速定位到问题所在，发现这与DataFusion引擎的一个配置选项有关。DataFusion提供了一个名为skip_physical_aggregate_schema_check的执行选项，可以跳过这种严格的模式检查。团队决定在短期内通过调整这个配置来解决问题，同时计划在后续版本中升级到修复了这个问题的DataFusion最新版本。

这个问题特别值得注意，因为它影响了使用CTE和GROUP BY组合查询的用户场景，而这种模式在分析型查询中相当常见。对于使用GreptimeDB进行时序数据分析的用户来说，了解这个限制非常重要，特别是在从0.11.3升级到0.12版本时。

开发团队已经确认将在即将发布的0.12.1版本中修复这个问题。对于遇到此问题的用户，建议暂时回退到0.11.3版本，或者等待0.12.1版本的发布。这个案例也展示了开源社区响应和解决问题的效率，从问题报告到确认原因和解决方案只用了很短的时间。

作为时序数据库领域的专家，我建议用户在进行版本升级时，特别是在生产环境中，应该充分测试所有关键查询，以确保兼容性。同时，理解底层查询引擎(如DataFusion)的变化对上层查询的影响也很重要，这有助于更快地定位和解决类似问题。