作者：Ming Ying 于 2026 年 10 月 1 日 两周前，Planet Scale 发布了 TIN，一个用于 Postgres 的全文搜索扩展。他们的发布文章报告了在 Parade DB 文本搜索功能子集上的令人印象深刻的性能优势，特别是 BM25 排名文本搜索和文档计数。我们要向 Planet Scale 团队表示祝贺。很高兴看到另一个 Postgres 平台在搜索方面进行投资，很明显 TIN 背后进行了大量深思熟虑的工程工作。
让我们非常明确一点：TIN 很快（在每一个 Planet Scale 基准测试中至少比 Parade DB 0.25 快 8x）。如此之快，以至于唯一合理的反应就是闭嘴并戴上我们的性能优化帽子。两周后，这是使用相同的 Stack Exchange 基准数据集、测试工具和机器类型的 BM25 排名前后对比。
有趣的不是我们迅速缩小了差距，而是我们如何缩小了差距。TIN 的文章声称他们的性能是由于一个根本性的架构差异，即使用 Postgres 的内部 ctid 字段作为文档标识符。然而，我们通过一些与文档标识方式关系不大的优化过程缩小了这一差距。
任何文本搜索索引的核心都是一个倒排列表。Parade DB 背后的搜索库 Tantivy 为其倒排列表使用顺序的 u32 文档 ID。Postgres 通过 ctid 值标识其行。TIN 文章的关键在于直接使用 ctid 值作为文档标识符消除了这种映射，并实现了高效的位图操作和可见性检查。对于 BM25 Top K 查询，我们持怀疑态度。
来源: Hacker News · 由HeadlinesBriefing整理摘要