TIN：让 Postgres 全文搜索快得离谱
Tin: full-text search for Postgres
PlanetScale 正式推出 TIN，一款专为 Postgres 打造的全文搜索扩展。TIN 不仅支持布尔表达式、模糊匹配和 BM25 排序，还能在并发写入时保持高性能。基准测试显示，TIN 的查询吞吐量是 ParadeDB 的 25 倍，延迟低 26 倍，甚至在索引更新时也能维持稳定。其核心优势在于直接利用 Postgres 的 ctid 作为文档标识，实现了高度向量化的索引操作，彻底解决了传统方案在复杂查询和写入冲突下的性能瓶颈。
TIN 也真的很快，快得令人难以置信。
HN 评论区
95- andrenotgiant
我觉得现在每家数据库公司都在推出新的全文搜索功能，这正是 AI 编程生产力在现实世界中的体现。
它始于 paradeDB 和 pg_search https://www.paradedb.com/blog/introducing-search
Timescale 推出了 pg_textsearch https://github.com/timescale/pg_textsearch
Neon 和 Databricks 有 Lakebase Search https://docs.databricks.com/aws/en/oltp/projects/lakebase-se...
现在轮到 PlanetScale 了。
据我所知，所有这些实现都是基于 BM25 算法。你只需要告诉一个 AI 代理去阅读关于 BM25 的资料，然后在你选择的系统中实现它。看到这一幕挺酷的。似乎架构设计和与各个系统的集成方面还有很大挖掘空间，但也不得不让人担心这是否会导致该领域被激进地商品化。
- Tiberium
如果 anyone 感兴趣的话 - https://planetscale.com/docs/postgres/search/get-started#loc...：
他们目前并没有提供具有相同性能的本地扩展——该功能仅在他们的云服务上提供。
本地版本 https://github.com/planetscale/lead 主要用于测试语法，不具备相同的性能特征。
- tannhaeuser
Postgres 本身就有 pg_fts（tsvector/tsquery/tsrank），这是一个集成了函数索引和查询优化的相当成熟的全文搜索包。我为什么要用某个靠“感觉”写出来的、并非 Postgres 核心组件的东西呢？
- groundzeros2015
请去读一下 Postgres 的手册。它内置了令人难以置信的搜索能力。
- usernametaken29
有趣的是，SQLite 的 FTS 开箱即用就支持 Lucene 查询，且性能表现极佳。据我所记，唯一的问题是写入操作在一段时间后变得相当慢。
我一直很好奇，到底是什么阻碍了 PostgreSQL 将这种实现集成到自己的数据库中。我对 ts_query 的体验一直不太理想。它确实比 LIKE 好一点，但只是好那么一点点，而且代价是索引大小变得极其庞大……
如果这个扩展能开源，让我们能在真实环境中测试一下，我相信一定能找到那个最佳平衡点。