加载失败
这篇 Show HN 介绍的是一个给 Postgres 增加 BM25 排序的搜索扩展，评论里同时提到 pg_search、pg_textsearch 和 ParadeDB 等同类项目。讨论的背景是很多团队希望在现有 Postgres 里直接做全文检索、hybrid search 和 RAG，而不是再外挂 Elasticsearch 之类的独立搜索系统。评论者还用 MS-MARCO 这类常见基准来衡量大规模文档的建索引速度，关心的重点不只是查询性能，还有初始化成本。另一条重要线索是许可证选择：AGPL 与更宽松的 PostgreSQL license 之间的取舍，会直接影响商业可用性和社区观感。
很多评论者认为，把 BM25 直接放进 Postgres 很实用，因为他们本来就在用 Postgres FTS 做 hybrid search、RAG 和 rerank。相比再外挂 Elasticsearch，这种方式能减少系统复杂度，也更适合在现有数据库里直接迭代和测试。有人明确说自己现在就在做类似方案，所以对这个发布非常兴奋，甚至直接问什么时候能在 Supabase 上用到。
有人最关心的不是查询速度，而是大表初次建索引要多久，因为很多 Postgres 扩展在百万级数据上会卡在初始化阶段。回复给出了基准：MS-MARCO v2（1.38 亿文档、约 50GB 原始数据）可以在不到 18 分钟内完成索引。另一个补充说，8M 文档在便宜的 GitHub runner 上大约 1 分钟就能建好，这让 200 万行级别的数据看起来更可控。
有评论指出，README 里的示例更像是在做 BM25 排序，但没有清楚展示“先过滤匹配 term，再按相关性排序”的完整工作流。示例里用 `< -5.0` 这种阈值看起来像 magic number，因为 BM25 分数会随数据集变化，很难提前确定一个通用阈值。回复承认这个例子不够好，并解释目前可以用 SQL 的后过滤、预过滤以及 planner 结合索引来绕开，但这部分的 ergonomics 仍然需要在 GA 之后继续打磨。
另一条分支直接转向许可证争论。有人把 ParadeDB 的 AGPL 视为限制，并借机称赞 TigerData 发布了一个使用 Postgres license 的开源替代方案。随后有人反驳这种“pernicious entity”的说法，强调选择更宽松的许可证是因为商业上可接受，而不是不够开源，反而是对 OSS 社区更友好的做法。
BM25: 一种基于词频、逆文档频率和文档长度的相关性排序算法，常用于搜索结果排名。
ts_vector(): Postgres 内置全文检索相关的向量/函数，用于分词、索引和 FTS 匹配。
RAG: Retrieval-Augmented Generation，先检索相关资料再交给模型生成答案的流程。
AGPL: 一种较强约束的开源许可证，网络服务使用场景下对公开修改的要求更严格。
MS-MARCO: 微软发布的搜索与排序基准数据集，常用于评测检索系统性能。