Postgres憋了8年的搜索短板，被3.4k星开源项目截胡了

PostgreSQL的全文搜索功能，过去8年几乎没动过。开发者吐槽它像"用菜刀做手术"——能切，但精准度感人。2025年4月，Timescale团队扔出一个3.4k星的项目，直接把BM25算法塞进了Postgres内核。这不是插件，是手术刀级别的改造。

BM25是信息检索领域的黄金标准，Elasticsearch和Lucene用了二十年。Postgres原生支持的是基于TF-IDF的tsvector，排名效果差一个量级。

Timescale的pg_textsearch项目，核心就一件事：让Postgres原生支持BM25相关性排序。v1.0.0已经标记为Production ready，支持PostgreSQL 17和18。Linux和macOS的amd64、arm64都有预编译二进制包。

安装方式粗暴直接。先改postgresql.conf，把pg_textsearch加进shared_preload_libraries，重启。然后CREATE EXTENSION，两步完事。索引创建语法是CREATE INDEX ... USING bm25，查询用<@>运算符。

BM25到底强在哪

TF-IDF算词频和逆文档频率，但不管文档长度。短文档天然占便宜，长文档哪怕内容相关也被压到后面。BM25加了长度归一化和饱和函数，长文档不再被歧视，词频也不会无限累加。

举个例子：搜"database system"。Postgres原生的tsvector可能把一句带这两个词的短句排到前面，真正系统性的技术文档因为篇幅长被埋没。BM25会综合考量词频、文档长度、字段平均长度，把真正相关的长文档捞上来。

pg_textsearch的实现细节很干净。索引结构用了自定义的BM25索引访问方法，不是基于GIN或GIST的包装。查询时<@>运算符返回负的BM25分数，因为Postgres的索引扫描只支持ASC顺序，分数越低表示匹配越好。

为什么是现在

Timescale做时序数据库起家，pg_textsearch看起来是跨界，实则逻辑自洽。他们的客户大量存储日志、事件流，文本检索是刚需。用Elasticsearch做外围索引？数据同步延迟、架构复杂度、运维成本，全是坑。

「我们试过所有方案，最后决定自己写。」Timescale工程师在HN原帖里没多解释，但代码量说明问题：209次提交，完整的benchmark套件，还有OPTIMIZATION_ROADMAP.md列着后续计划。

路线图上的待办包括：多语言配置优化、增量索引更新、查询性能调优。已经做完的是英语配置的默认支持，text_config='english'开箱即用。

对现有生态的冲击

pg_search、ZomboDB这些Postgres搜索插件突然尴尬了。pg_search基于pgrusty，用Rust重写BM25，但依赖外部服务。ZomboDB把Postgres当查询层，实际索引在Elasticsearch里。

pg_textsearch走的是第三条路：纯内核扩展，零外部依赖。查询计划和执行都在Postgres内部完成，优化器能看懂成本，EXPLAIN ANALYZE输出干净。

benchmark数据还没大规模公开，但项目自带的benchmarks目录里有测试框架。用的数据集和查询模式，应该能直接复现。

一个细节值得玩味：项目原名Tapir，貘，Postgres信息检索的文本分析工具。代码里还留着tapir的痕迹，但对外品牌统一成了pg_textsearch。 mascot没换，文档里还画着那只貘。

PostgreSQL 18的开发周期里，这个扩展会不会被吸收进核心？Timescale的人没表态。但看shared_preload_libraries的加载方式，他们已经按最高规格对接内核接口了。

你现在的Postgres全文搜索方案是什么？如果BM25能原生支持，迁移成本和技术债，哪个更让你头疼？