ParadeDB项目中自定义扫描执行模式选择的技术优化

背景介绍

在数据库系统中，查询优化器负责将SQL查询转换为高效的执行计划。ParadeDB作为一个开源数据库项目，在其pg_search模块中实现了一种自定义扫描机制，用于处理全文搜索等特殊查询场景。这种自定义扫描机制允许开发者灵活地定义查询计划和执行方式。

问题分析

当前ParadeDB的实现中存在一个设计上的不足：自定义扫描的执行模式选择被推迟到了执行阶段（create_custom_scan_state函数），而相关的计划属性（如排序方向、限制数量等）却在规划阶段（callback函数）就已经设置。这种分离导致了几个问题：

1. 决策不一致风险：规划阶段设置的属性在执行阶段可能不会被实际使用，因为执行模式的选择是独立的
2. 属性声明困难：规划阶段难以准确声明计划属性（如是否排序），因为这些属性取决于执行阶段的选择
3. 代码维护困难：两个阶段的逻辑耦合度高，修改时容易出错

技术方案

为了解决这些问题，我们提出了以下优化方案：

1. 引入执行模式枚举类型：定义一个包含所有可能执行模式的枚举类型，封装每种模式所需的参数

   pub enum ExecMethodType {
       TopN {
           limit: usize,
           sort_direction: SortDirection,
       },
       FastFieldString {
           which_fast_fields: Vec<WhichFastField>,
       },
       FastFieldNumeric {
           which_fast_fields: Vec<WhichFastField>,
       },
       Normal,
   }
   

2. 提前执行模式选择：将执行模式的选择从执行阶段移动到规划阶段，在callback函数中完成

3. 基于执行模式声明计划属性：在规划阶段就能准确知道将使用哪种执行模式，从而正确声明排序等属性

实现细节

在具体实现上，我们需要：

1. 重构CustomPathBuilder，使其能够保存确定的执行模式
2. 修改规划逻辑，基于查询条件提前选择合适的执行模式
3. 在执行阶段直接使用规划阶段确定的执行模式，不再重复决策
4. 确保所有执行模式所需的参数都在规划阶段收集完整

优势与收益

这种优化带来了多方面的好处：

1. 决策一致性：执行模式的选择和属性声明现在统一在规划阶段完成，避免了不一致
2. 性能优化：规划器可以基于确定的执行模式进行更准确的成本估算和路径选择
3. 代码清晰度：消除了规划阶段和执行阶段之间的隐含依赖，逻辑更加清晰
4. 可维护性：减少了两个阶段之间的耦合，降低了未来修改时引入错误的风险

实际案例

在实际应用中，这种优化特别解决了排序声明的问题。例如，只有当选择TopN执行模式时，结果才保证是有序的。在优化前，规划阶段需要猜测执行阶段是否会选择TopN模式来声明排序属性；优化后，规划阶段可以确切知道将使用TopN模式，从而准确声明排序属性。

总结

将自定义扫描执行模式的选择从执行阶段提前到规划阶段，是ParadeDB项目中的一项重要架构优化。它不仅解决了当前存在的几个具体问题，还为未来的功能扩展奠定了更清晰的基础。这种"早绑定"的设计模式在数据库系统中很常见，能够提高系统的可预测性和可维护性。

对于数据库开发者而言，理解查询规划与执行之间的这种交互关系，对于设计和实现高效、可靠的查询处理器至关重要。ParadeDB的这次优化展示了如何通过合理的架构设计来解决实际开发中遇到的复杂问题。