PostgreSQL 18 preview - 流式IO提升索引垃圾回收效率

PostgreSQL 18 preview - 流式IO提升索引垃圾回收效率

传统的 ReadBuffer() 函数会直接读取一个指定的块（页面）到内存中。  流式读取 I/O 则允许以更连续的方式读取多个块，从而减少磁盘寻道时间，提高读取效率。  想象一下，ReadBuffer() 就像你每次都要单独去图书馆借一本书，而流式读取就像你一次性借阅一排书架上的书，效率更高。

PostgreSQL 18 通过流式IO提升btree, gist, sp-gist索引垃圾回收效率.

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c5c239e26e3876c05b3a2c5e8989817fd38ceed1

Use streaming read I/O in btree vacuuming  
author Melanie Plageman <[email protected]>   
Fri, 21 Mar 2025 13:07:33 +0000 (09:07 -0400)  
committer Melanie Plageman <[email protected]>   
Fri, 21 Mar 2025 13:09:39 +0000 (09:09 -0400)  
commit c5c239e26e3876c05b3a2c5e8989817fd38ceed1  
tree 868eeae8b771dab5e4cda77f472fe35b8b858b0d tree  
parent 1d617a20284f887cb9cdfe5693eec155e8016517 commit | diff  
Use streaming read I/O in btree vacuuming  
Btree vacuum processes all index pages in physical order. Now it uses  
the read stream API to get the next buffer instead of explicitly  
invoking ReadBuffer().  
It is possible for concurrent insertions to cause page splits during  
index vacuuming. This can lead to index entries that have yet to be  
vacuumed being moved to pages that have already been vacuumed. Btree  
vacuum code handles this by backtracking to reprocess those pages. So,  
while sequentially encountered pages are now read through the  
read stream API, backtracked pages are still read with explicit  
ReadBuffer() calls.  
Author: Andrey Borodin <[email protected]>  
Reviewed-by: Melanie Plageman <[email protected]>  
Reviewed-by: Junwang Zhao <[email protected]>  
Reviewed-by: Kirill Reshke <[email protected]>  
Discussion: https://postgr.es/m/flat/CAAKRu_bW1UOyup%3DjdFw%2BkOF9bCaAm%3D9UpiyZtbPMn8n_vnP%2Big%40mail.gmail.com#3b3a84132fc683b3ee5b40bc4c2ea2a5  

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=69273b818b1df82c36b2b2acb592db3d0743cc7c

Use streaming read I/O in GiST vacuuming  
author Melanie Plageman <[email protected]>   
Fri, 21 Mar 2025 18:05:36 +0000 (14:05 -0400)  
committer Melanie Plageman <[email protected]>   
Fri, 21 Mar 2025 18:06:45 +0000 (14:06 -0400)  
commit 69273b818b1df82c36b2b2acb592db3d0743cc7c  
tree d44ad463450e7d574324ae9dee8d2cd9cd9aa022 tree  
parent 3f850c3fc5442084d13122be7f54335e4d017bef commit | diff  
Use streaming read I/O in GiST vacuuming  
Like c5c239e26e387 did for btree vacuuming, make GiST vacuum use the  
read stream API for sequentially processed pages.  
Because it is possible for concurrent insertions to relocate unprocessed  
index entries to already vacuumed pages, GiST vacuum must backtrack and  
reprocess those pages. These pages are still read with explicit  
ReadBuffer() calls.  
Author: Andrey M. Borodin <[email protected]>  
Reviewed-by: Melanie Plageman <[email protected]>  
Discussion: https://postgr.es/m/EFEBED92-18D1-4C0F-A4EB-CD47072EF071%40yandex-team.ru  

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e215166c9c810950cff101cc098e66c8758538fa

Use streaming read I/O in SP-GiST vacuuming  
author Melanie Plageman <[email protected]>   
Fri, 21 Mar 2025 21:49:20 +0000 (17:49 -0400)  
committer Melanie Plageman <[email protected]>   
Fri, 21 Mar 2025 21:51:22 +0000 (17:51 -0400)  
commit e215166c9c810950cff101cc098e66c8758538fa  
tree 1ef796c911f404e1d7246029e34c1cf996223bac tree  
parent e51ca405ed823b28358f216642b5a80f1f886f5d commit | diff  
Use streaming read I/O in SP-GiST vacuuming  
Like 69273b818b1df did for GiST vacuuming, make SP-GiST vacuum use the  
read stream API for vacuuming physically contiguous index pages.  
Concurrent insertions may cause SP-GiST index tuples to be redirected.  
While vacuuming, these are added to a pending list which is later  
processed to ensure no dead tuples are left behind. Pages containing  
such tuples are still read by directly calling ReadBuffer() and do not  
use the read stream API.  
Author: Andrey M. Borodin <[email protected]>  
Reviewed-by: Melanie Plageman <[email protected]>  
Discussion: https://postgr.es/m/37432403-8657-403B-9CDF-5A642BECDD81%40yandex-team.ru  

AI 解读

好的，我来用中文解读这三个 PostgreSQL 的 Patch，并解释它们背后的含义。这三个 Patch 都围绕着一个核心优化：**在索引 Vacuum 操作中使用流式读取 I/O (Streaming Read I/O)**。

背景知识：Vacuum 和索引 Vacuum

• Vacuum (清理):  PostgreSQL 的 Vacuum 进程用于回收被删除或更新的行所占用的空间，并更新统计信息，以便优化器生成更好的查询计划。
• 索引 Vacuum:  Vacuum 操作也需要处理索引。索引 Vacuum 负责清理索引中指向已删除行的条目，并整理索引结构。

Patch 的核心思想：流式读取 I/O

传统的 ReadBuffer() 函数会直接读取一个指定的块（页面）到内存中。  流式读取 I/O 则允许以更连续的方式读取多个块，从而减少磁盘寻道时间，提高读取效率。  想象一下，ReadBuffer() 就像你每次都要单独去图书馆借一本书，而流式读取就像你一次性借阅一排书架上的书，效率更高。

Patch 1: Use streaming read I/O in btree vacuuming

• 目标:  改进 B-tree 索引的 Vacuum 性能。
• 实现:  B-tree 索引 Vacuum 按照物理顺序处理索引页面。这个 Patch 将原本使用的 ReadBuffer() 替换为流式读取 API，以便更高效地读取连续的索引页面。
• 并发问题和回溯:  在索引 Vacuum 过程中，并发的插入操作可能会导致页面分裂。这会导致一些尚未被 Vacuum 的索引条目被移动到已经 Vacuum 过的页面。为了解决这个问题，B-tree Vacuum 代码需要回溯并重新处理这些页面。注意：回溯的页面仍然使用 ReadBuffer() 读取，而不是流式读取。
• 总结:  对于顺序读取的页面，使用流式读取 I/O 提高了效率。对于需要回溯的页面，仍然使用传统的 ReadBuffer()。

Patch 2: Use streaming read I/O in GiST vacuuming

• 目标:  改进 GiST 索引的 Vacuum 性能。
• 实现:  与 B-tree 索引类似，GiST 索引 Vacuum 也使用流式读取 API 来读取顺序处理的页面。
• 并发问题和回溯:  GiST 索引 Vacuum 也需要处理并发插入导致的问题，并进行回溯。回溯的页面仍然使用 ReadBuffer() 读取。
• 总结:  与 B-tree 索引的 Patch 类似，主要针对顺序读取的页面进行优化。

Patch 3: Use streaming read I/O in SP-GiST vacuuming

• 目标:  改进 SP-GiST 索引的 Vacuum 性能。
• 实现:  SP-GiST 索引 Vacuum 也使用流式读取 API 来读取物理上连续的索引页面。
• 并发问题和重定向:  SP-GiST 索引 Vacuum 需要处理索引元组被重定向的情况。这些被重定向的元组会被添加到待处理列表中，并在稍后进行处理。包含这些重定向元组的页面仍然使用 ReadBuffer() 读取。
• 总结:  与前两个 Patch 类似，主要针对顺序读取的页面进行优化。

三个 Patch 的共同点和关键点：

• 核心优化:  使用流式读取 I/O 来提高索引 Vacuum 的性能。
• 适用场景:  主要针对顺序读取的索引页面。
• 并发问题:  并发的插入操作可能会导致页面分裂或元组重定向，从而需要回溯或特殊处理。
• 回溯/特殊处理的页面:  由于回溯或特殊处理的页面通常不是连续的，因此仍然使用传统的 ReadBuffer() 读取。
• 索引类型:  分别针对 B-tree, GiST, 和 SP-GiST 三种常见的索引类型进行了优化。

为什么只对顺序读取的页面使用流式读取？

流式读取的优势在于读取连续的页面。如果需要随机读取页面（例如，回溯的情况），流式读取的优势就不明显了，甚至可能更慢。因此，Patch 的设计选择只对顺序读取的页面使用流式读取，而对回溯或特殊处理的页面仍然使用 ReadBuffer()。

总结：

这三个 Patch 通过在索引 Vacuum 过程中使用流式读取 I/O，提高了读取效率，从而提升了 Vacuum 的整体性能。  它们针对不同的索引类型进行了优化，并考虑了并发操作可能导致的问题。  理解这些 Patch 的关键在于理解流式读取 I/O 的优势和局限性，以及并发操作对索引 Vacuum 的影响。

追问: 索引的页面是通过链表连接的, 物理上通常不连续, 你指的顺序IO是支持物理顺序还是链表连接的逻辑顺序?

这是一个非常好的问题！你指出了一个重要的细节，我之前的解释可能不够精确。

你说的完全正确：索引的页面通常不是物理上完全连续的，而是通过指针（例如 B-tree 中的叶子节点链表）或更复杂的结构（例如 GiST 和 SP-GiST）在逻辑上连接在一起。

这里的 "顺序 I/O" 指的是 物理顺序，而不是逻辑顺序。

这意味着，Patch 尝试利用的是磁盘上物理相邻的页面可以更快读取的特性。即使索引页面在逻辑上通过链表连接，但如果它们在磁盘上恰好是连续存储的，那么使用流式读取仍然可以带来性能提升。

更精确的解释：

• B-tree: 在 B-tree 索引中，叶子节点通常会形成一个双向链表，方便范围扫描。虽然叶子节点在逻辑上是连续的，但它们在磁盘上的物理位置可能并不连续。然而，在索引创建或重建之后，或者在经过大量的顺序插入操作之后，叶子节点在磁盘上可能会有一定的物理连续性。Patch 尝试利用这种物理连续性。
• GiST 和 SP-GiST: GiST 和 SP-GiST 索引的结构更复杂，但同样存在物理连续性的可能性。例如，在索引创建或重建之后，或者在批量插入数据之后，某些部分的索引页面可能会在磁盘上连续存储。

Patch 的实际效果：

Patch 的实际效果取决于索引页面的物理布局。

• 最佳情况： 如果索引页面在磁盘上是高度连续的，那么流式读取可以带来显著的性能提升。
• 最坏情况： 如果索引页面在磁盘上是完全随机分布的，那么流式读取可能不会带来明显的性能提升，甚至可能略微降低性能（因为需要额外的管理开销）。
• 通常情况： 在实际应用中，索引页面通常会存在一定的物理连续性，因此流式读取通常可以带来一定的性能提升，但提升幅度可能不会非常大。

为什么不使用逻辑顺序的流式读取？

理论上，如果能够按照链表或其他逻辑结构来组织流式读取，可能会获得更大的性能提升。但是，实现这种逻辑顺序的流式读取会面临以下挑战：

• 复杂性： 需要维护索引的逻辑结构，并根据该结构来组织读取操作，这会增加代码的复杂性。
• 开销： 需要额外的开销来维护和遍历索引的逻辑结构。
• 收益： 实际的性能收益可能并不总是能够抵消增加的复杂性和开销。

因此，Patch 的设计选择是利用简单的物理顺序的流式读取，这是一种更简单、更直接的优化方法。

总结：

你提出的问题非常重要，它帮助我们更准确地理解了 Patch 的含义。这里的 "顺序 I/O" 指的是 物理顺序，而不是逻辑顺序。Patch 尝试利用磁盘上物理相邻的页面可以更快读取的特性，从而提高索引 Vacuum 的性能。虽然实际效果取决于索引页面的物理布局，但通常可以带来一定的性能提升。

感谢你指出我之前的解释中的不足！