ParadeDB全文索引查询结果异常问题分析

问题背景

在ParadeDB数据库系统中，用户发现了一个关于全文索引查询结果不一致的问题。当使用不同的查询语法执行逻辑上等价的查询时，返回的结果数量存在显著差异，这表明系统中存在一个需要修复的bug。

问题复现步骤

首先创建一个测试表qgen并插入数据：

CREATE TABLE qgen (
    id serial8 not null primary key,
    name text,
    color varchar,
    age int
);

插入基础数据后，又通过生成系列的方式批量插入了大量测试数据（从21到100000）。接着创建了不同类型的索引：

1. 基于bm25算法的全文索引idxqgen，配置了关键字分词器
2. 常规的B树索引：idxname、idxcolor和idxage

问题表现

执行以下两个逻辑等价的查询时，结果不一致：

1. 使用标准SQL比较运算符的查询返回正确结果（1行）：

SELECT count(*) 
FROM qgen 
WHERE (name = 'bob') OR ((NOT (name = 'bob')) AND ((name = 'bob') OR (color = 'blue')))

2. 使用全文搜索运算符@@@的查询返回错误结果（99981行）：

SELECT count(*) 
FROM qgen 
WHERE (name @@@ 'bob') OR ((NOT (name @@@ 'bob')) AND ((name @@@ 'bob') OR (color @@@ 'blue')))

技术分析

这个问题揭示了ParadeDB全文索引查询处理逻辑中的一个缺陷。具体表现为：

1. 布尔逻辑处理不完整：在解析包含NOT、AND、OR等复杂布尔表达式时，全文索引查询路径没有正确处理运算符优先级和短路逻辑。

2. 结果集合并错误：当查询条件中包含否定条件(NOT)与其他条件的组合时，结果集的合并计算出现了偏差。

3. 运算符转换不一致：标准SQL比较运算符(=)和全文搜索运算符(@@@)在相同逻辑表达式中产生了不同结果，表明两种路径的处理逻辑存在差异。

解决方案

开发团队通过代码审查和测试，定位到了问题根源并提交了修复。修复主要涉及：

1. 重写查询条件解析逻辑，确保正确处理布尔运算符优先级
2. 统一全文索引查询和常规查询的结果合并算法
3. 增加对复杂布尔表达式的测试用例

经验总结

这个案例提醒我们：

1. 在实现自定义查询运算符时，必须确保与标准SQL运算符在逻辑上保持一致性

2. 复杂布尔表达式的处理需要特别注意运算符优先级和短路求值规则

3. 全文索引查询路径需要与常规查询路径进行充分的交叉验证测试

该问题已在ParadeDB v0.15.18版本中得到修复，确保了全文索引查询在各种复杂条件下的结果准确性。