主要观点：ParadeDB 完成将 pg_search（Postgres 全文搜索和分析扩展）迁移到 Postgres 块存储系统的重大工程，这是首个将外部文件格式移植到 Postgres 块存储的扩展，迁移后实现了诸多优势，如与 Postgres 写前日志（WAL）集成、崩溃和时间点恢复、对 MVCC 的全面支持以及与缓冲区缓存的集成等。文中详细介绍了块存储的概念、pg_search及其迁移到块存储的原因，以及 Tantivy 的基于文件的索引布局和迁移到块存储布局过程中面临的挑战及解决方案。

关键信息：

• 块存储的基本单位是 8192 字节的块，DML 语句不修改物理块，修改写入缓冲区，崩溃时未刷新的缓冲区修改可能丢失，需写入 WAL 以恢复数据库。
• pg_search由 Tantivy 提供支持，实现了自定义全文搜索和分析索引。
• 迁移到块存储需解决数据结构适配、块管理、更新场景性能等问题，如大文件溢出单个块需链表存储，块不能内存映射需修改 Tantivy 以延迟字节解引用，更新场景中段数量易爆炸需引入 merge_on_insert 步骤。
• 后续将发布讨论 pg_search 在更新密集场景下的 MVCC 安全性以及针对分析工作负载定制块存储布局的帖子。

重要细节：

• 迁移前 pg_search 在块存储之外操作，创建不受 Postgres 管理的文件。
• 块存储能利用缓冲区缓存减少磁盘 I/O，提供简单的 WAL 写入 API，Postgres 处理文件创建和清理。
• Tantivy 索引由多个段组成，包括 postings、positions、terms 等文件，新段在提交新文档时创建，通过合并过程合并小段。
• 迁移到块存储布局时，段序列化为块，大段用链表存储，单独块存储索引模式等信息，利用 Postgres MVCC 可见性信息消除第二个可见段列表，不再需要 Tantivy 的锁文件，改用 Postgres 的缓冲区级互斥锁机制。
• 面对大文件溢出单个块的挑战，通过链表结构和特殊数据区实现 O(1)查找。
• 为解决块不能内存映射的问题，修改 Tantivy 以延迟解引用大字节切片并缓存已访问的块。
• merge_on_insert 步骤在插入后寻找合并机会，需保证只有一个合并进程并发运行，通过写入事务 ID 进行并发控制。