ParadeDB中多表连接导致BM25评分失效问题解析

问题现象

在使用ParadeDB进行全文搜索时，开发人员发现了一个奇怪的现象：当查询只涉及单个表或两个表连接时，BM25评分功能工作正常；但当查询涉及三个或更多表连接时，评分结果会意外地返回NULL值。

问题复现

通过以下步骤可以稳定复现该问题：

1. 创建两个带有BM25搜索索引的测试表mock_items和mock_items2
2. 创建一个普通表test作为对照
3. 在两表连接查询中，评分正常返回
4. 在三表连接查询中，评分变为NULL

技术分析

通过EXPLAIN VERBOSE分析查询计划，发现问题的根源在于PostgreSQL查询优化器的行为：

1. 在基础查询中，ParadeDB的自定义扫描节点(ParadeDB Scan)正确生成了评分结果
2. 但在多表连接场景下，Hash Join节点未能正确"拉取"扫描节点生成的评分值
3. 当评分函数最终应用到连接结果时，原始评分信息已经丢失，导致返回NULL

临时解决方案

在官方修复发布前，可以使用以下临时解决方案：

SELECT m1.score, m1.description
FROM (select paradedb.score(id), * from mock_items where description @@@ 'shoes' offset 0) m1
     join mock_items2 m2 on m1.id = m2.id
     join test t on m1.id = t.id;

关键点在于使用子查询并添加offset 0，这可以强制PostgreSQL保留评分结果。

问题本质

这实际上是一个PostgreSQL查询优化器与自定义扫描节点交互的问题。在多表连接场景下，优化器未能正确处理自定义扫描节点生成的额外列(评分结果)，导致这些列在连接操作中被丢弃。

官方修复

ParadeDB团队已在内部版本中修复了该问题，修复方案主要涉及：

1. 改进自定义扫描节点的列处理逻辑
2. 确保评分结果能正确通过连接操作传递
3. 优化查询计划生成过程

该修复将包含在下一个正式版本中发布。

最佳实践建议

对于使用全文搜索与复杂查询的场景，建议：

1. 尽量将搜索条件限制在单个主表上
2. 必要时使用子查询先获取评分结果
3. 关注官方更新，及时升级到包含修复的版本
4. 对关键查询进行EXPLAIN分析，验证评分逻辑是否按预期工作

总结

这个问题展示了数据库扩展开发中的典型挑战：当自定义功能与核心系统的查询优化器交互时，可能会出现意料之外的行为。ParadeDB团队通过深入分析查询计划，定位到了优化器与自定义扫描节点交互的问题，并提供了有效的解决方案。