pg_duckdb项目中CustomScan对反向扫描的支持问题分析

在PostgreSQL与DuckDB的集成项目pg_duckdb中，存在一个关于CustomScan执行器对反向扫描(backward scan)支持不足的技术问题。这个问题涉及到数据库查询执行的核心机制，值得深入探讨。

问题背景

在PostgreSQL中，当使用可滚动游标(SCROLL CURSOR)时，查询执行器需要支持双向遍历结果集的能力。PostgreSQL原生通过在查询计划顶部添加Materialize节点来确保这种能力。然而，pg_duckdb项目中的CustomScan实现目前未能正确处理这种情况。

技术细节

PostgreSQL处理可滚动游标的典型流程是：

1. 优化器生成最佳查询路径
2. 创建对应的执行计划
3. 检查游标选项是否包含SCROLL标志
4. 如果执行计划不支持反向扫描，则在顶部添加Materialize节点

pg_duckdb的CustomScan实现覆盖了整个查询计划生成过程，但遗漏了对反向扫描能力的检查和处理。这导致当使用SCROLL游标并尝试反向获取数据(FETCH PRIOR)时，系统可能会崩溃或产生不正确的结果。

影响范围

虽然当前版本的pg_duckdb通过限制多语句事务中的DuckDB执行暂时避免了这个问题，但从架构设计角度看，这仍是一个需要解决的根本性问题。特别是在以下场景中可能会暴露问题：

• 使用SCROLL游标进行双向遍历
• 需要支持结果集反向扫描的复杂查询
• 某些分析型查询需要多次遍历同一结果集

解决方案建议

要彻底解决这个问题，可以考虑以下技术方案：

1. 完整实现反向扫描支持：在CustomScan中完整实现ExecSupportsBackwardScan接口，确保与PostgreSQL原生行为一致。

2. 自动添加Materialize节点：在查询计划生成阶段检测是否需要反向扫描能力，必要时自动添加Materialize节点。

3. 执行时检查机制：在执行阶段增加安全检查，当检测到不支持的扫描方向时，优雅地返回错误而非崩溃。

技术考量

实现这一功能时需要考虑以下技术因素：

• 性能影响：Materialize节点会增加内存使用和计算开销
• 兼容性：需要确保与PostgreSQL其他特性的兼容性
• 执行效率：在不需要反向扫描时避免不必要的Materialize操作

总结

pg_duckdb项目中CustomScan对反向扫描的支持不足是一个典型的数据库执行引擎集成问题。解决这个问题不仅能提高系统的稳定性，还能增强与PostgreSQL原生功能的兼容性。未来在解除多语句事务限制后，这一问题将变得更加重要，建议在架构设计阶段就予以充分考虑和解决。