Trino项目中exclude_columns函数的谓词下推优化分析

在Trino分布式SQL查询引擎中，表函数exclude_columns是一个非常有用的功能，它允许用户从查询结果中排除指定的列。然而，当前版本中存在一个性能优化问题：当使用exclude_columns函数时，查询谓词无法下推到表扫描操作中。

问题背景

在SQL查询优化中，谓词下推(Predicate Pushdown)是一个重要的优化技术。它能够尽早地过滤数据，减少后续处理的数据量。但在使用exclude_columns函数时，如以下查询：

SELECT * 
FROM TABLE(exclude_columns(
  input => TABLE(tpch.sf1.customer), 
  columns => DESCRIPTOR(c_comment)
))
WHERE c_custkey = 1

虽然用户期望c_custkey = 1的过滤条件能够下推到customer表的扫描阶段，但实际上这个谓词无法被下推。这会导致系统需要先扫描整个表，然后再应用过滤条件，造成不必要的性能开销。

技术挑战分析

Trino核心开发团队深入分析了这个问题，发现存在几个关键的技术难点：

1. 表函数的参数语义差异：

   • 行语义参数：函数结果基于每行数据计算
   • 集合语义参数：函数结果基于分区数据计算

2. 表函数输出的列类型：

   • 派生列：由表函数生成的新列
   • 透传列：直接从输入传递到输出的列

谓词下推只能在行语义参数和透传列的情况下安全进行。而exclude_columns函数的当前实现将所有列都视为派生列，这阻碍了谓词下推的优化。

解决方案

经过讨论，团队提出了两种可能的解决方案：

1. 通用解决方案：扩展Trino的SPI接口，让连接器能够基于特定函数的语义决定是否进行谓词下推。这种方法虽然全面，但实现复杂，需要谨慎设计。

2. 专用优化：针对exclude_columns这个内置函数，将其重写为投影操作。这种方法实现简单，能直接解决问题。

最终团队选择了第二种方案，因为它能快速解决问题且实现成本低。通过将exclude_columns重写为投影操作，可以保留原有的谓词下推优化能力，同时保持函数的语义不变。

实现效果

这种优化实施后，用户无需改变查询写法就能获得谓词下推带来的性能提升。对于包含exclude_columns的复杂查询，特别是处理大表时，性能提升将非常显著。

总结

Trino团队通过分析表函数的特性和查询优化机制，找出了阻碍谓词下推的关键因素，并采用针对性的优化方案解决了问题。这个案例展示了数据库查询优化器设计中需要考虑的各种因素，以及如何在保证功能正确性的前提下实现性能优化。