加载失败
这是一条 Show HN，介绍 pg_textsearch（一个为 PostgreSQL 提供 BM25 搜索能力的开源扩展）的 v1.0。讨论把它放在更大的搜索栈背景下：很多团队原本用 PostgreSQL 的 `ts_vector()` 做全文检索，再叠加 pgvector（一个 PostgreSQL 向量检索扩展）做 hybrid search，或者直接上 Elasticsearch（独立搜索引擎）。这次发布之所以引发关注，是因为它承诺把 BM25、向量检索、RAG（检索增强生成）相关工作更多地收回到数据库里，同时还强调免费、自托管和高性能基准。评论里还穿插了对 ParadeDB / pg_search（另一套 PostgreSQL 搜索扩展）、以及 GCP、Cloud SQL、Aurora、Supabase、Neon 等托管数据库能否支持该扩展的现实讨论。
评论里最集中的问题是能不能真正在大数据量下跑得动。有人关心内存占用、lock contention 和初始建索引时间，尤其是几百万到上亿文档时扩展是否会先卡在导入而不是查询。回应给出的数字很亮眼：MS-MARCO v2 1.38 亿文档、约 50GB 原始数据，索引时间略低于 18 分钟；在 200 万行规模上，低端硬件也大约 1 分钟。与此同时，维护者也承认高频写入和查询性能之间确实有权衡，当前用 memtable spill 和 compaction 的可调参数缓解，但这部分还没有完全做完。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
很多人把它看成 Postgres 里补齐 BM25 的关键拼图。讨论焦点不是单纯关键词搜索，而是和 pgvector（PostgreSQL 向量检索扩展）一起做 hybrid search，服务 RAG（检索增强生成）和 rerank 场景。有人提到可以在 SQL 里做 reciprocal rank fusion（RRF）把 lexical 和 semantic 两路结果合并，也有人强调输入清洗和预处理往往比检索算法本身更决定效果。项目方的态度是：混合检索是核心目标之一，但怎么组合 keyword、vector 和 reranking 主要留给应用层决定。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
也有人抓住了功能边界问题。一个明显担忧是 term positions：如果扩展依赖词位信息，它对日志、商品描述这类人类可读搜索会不会不够灵活。README 里那个用 `-5.0` 作为过滤阈值的例子也被认为很别扭，因为 BM25 分数和阈值会随数据集变化，很难事先猜对。回复里提到可以用后过滤、按条件先过滤再排序、分区表，甚至未来的 expression indexes，但也承认这种查询体验还不是很优雅。
生产可用性是另一条主线。有人已经在生产里跑了几周，反馈稳定且很快，并拿它和 ParadedB / pg_search 做对比，认为后者曾带来不稳定甚至数据损坏，最后只好先退回 trigram search。与此同时，很多人直接在问 GCP、Cloud SQL、Aurora、Supabase、Neon 和 Alloy 这些 managed Postgres 平台什么时候能支持这个扩展。回复显示至少在部分云环境里已经有推进，但最终还要看各家是否把它列进支持的 extension 清单。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
线程里还夹着一段明显的 license 和口碑争论。有人把 AGPL 视为商业上难以接受的限制，反过来称赞这个新项目用更宽松的 Postgres license 做了一个 OSS 替代方案。另一些人则认为把 TigerData 之类的团队骂成“有害实体”太过火，真正该讨论的是软件质量而不是阵营。也有人替作者辩护，强调他不是那种只会 vibe coding 的人，而是有实际履历、甚至曾在 API credits 上花过不少钱。
BM25: 一种常见的相关性排序算法，结合词频、文档长度等因素给搜索结果打分。
hybrid search: 把关键词检索和向量语义检索一起用，通常先召回再重排。
RAG: Retrieval-Augmented Generation，先检索相关资料，再交给生成模型回答。
pgvector: PostgreSQL 的向量扩展，用于 embedding 相似度检索。
RRF: reciprocal rank fusion，按多个结果列表中的名次融合重排。
term positions: 索引中记录词在文档里的位置，便于短语和邻近查询。
memtable: 先写入内存、再批量刷盘的结构，常见于 LSM 风格索引。
compaction: 把多个索引段合并压缩，减少碎片并提升查询性能。