背景介绍

PostgreSQL 对存储层的物理文件进行截断操作时，需要在 buffer pool 中把被截断页面对应的缓存页面给同步删除。已有的简单算法是遍历 buffer pool 中的每一个页面，将页面所属的物理文件 ID、块号与正被截断的物理文件 ID、截断长度进行比较。如果缓存页面属于被截断的部分，就从 buffer pool 中删除。该算法在部分场景下存在局限性：

• 当 buffer pool 较大而被删除的页面数较少时，以 O(n) 的时间复杂度遍历 buffer pool 中的每一个 8kB 的页面将会消耗大量无效 CPU
• Primary 节点的恢复和 Replica/Standby 节点的物理复制，均由 startup 单进程串行处理页面删除相关的逻辑，如果存在较多的页面删除动作，将会影响到恢复速度和复制延迟；Replica 节点的复制延迟还会进而影响到 Primary 节点上 DDL 的响应时间

当需要被删除的页面数量和 buffer pool 的大小差距悬殊时，更好的做法是通过 buffer mapping 表来快速定位待删除页面是否在 buffer pool 中。如果页面存在，则能够以 O(1) 的时间复杂度删除页面：buffer pool 的大小是固定的，被删除的页面数量可以由物理文件长度与截断长度相减得到。但获取物理文件长度存在以下问题：

1. 获取物理文件长度需要通过 系统调用，会发生 I/O，响应时间可能会比遍历 buffer pool 更久
2. 可以将上一次对物理文件长度的查询结果缓存在内存中，供后续直接使用；但 PostgreSQL 没有在多个进程之间同步物理文件长度变化的机制，因此缓存值只有在 recovery 等单进程工作的状态下才有效

对于 PolarDB-PG 来说，还有额外的问题：

1. PolarDB-PG 的 Primary 和 Replica 节点共享一份存储，Primary 节点截断文件和 Replica 节点回放截断日志是异步的，Replica 节点在回放到文件截断的 WAL 日志时，调用 已经无法返回正确的值
2. PolarDB-PG 的 Replica 节点只回放日志但不修改存储，而物理文件长度的缓存是在修改物理文件的存储层接口中被更新的，因此 Replica 节点无法通过回放 WAL 日志来更新缓存

PolarDB-PG 的 表大小缓存 (RSC) 能够解决以上问题：

1. RSC 存放在共享内存中，支持多进程并发更新或查询物理文件长度：进程通过一次内存搜索就可以快速获取物理文件长度，避免通过 发生 I/O
2. RSC 在 Replica 节点上通过回放 WAL 日志就能够推断出当前可见的文件长度，无需通过存储层接口更新缓存的物理文件长度值

借助 RSC，PolarDB-PG 支持在 Primary/Replica/Standby 三种节点角色的任意进程内都能够快速获取到正确的物理文件长度，并据此决定在删除页面时是否能够使用更快速的算法。

实现原理

本功能复用了 PostgreSQL 14+ 中的已有算法来判断是否使用 buffer mapping 加速页面删除：如果待删除的页面数量小于 页面数量的 1/32 时，则通过 buffer mapping 依次搜索每一个待删除页面，如果存在于 buffer pool 中，则从中移除。

此外，本功能还需要借助 RSC 的基础能力来快速获取表的物理文件长度。针对该场景的特点，需要对 RSC 进行如下改造：

1. 默认情况下，如果 RSC 搜索未命中，将会通过 调用获取当前物理文件的长度并更新缓存；在页面删除场景中，为 RSC 引入了 仅缓存搜索 模式，即在 RSC 搜索未命中时直接返回 ，从而回退使用遍历 buffer pool 的保守删除算法
2. Replica 节点在回放日志时，默认情况下仅更新 RSC 中已缓存的物理文件长度 (这些表近期在 Replica 节点上被访问过)；为了让 Replica 节点能够尽量减少使用保守删除算法，回放日志时，如果当前物理文件长度没有缓存在 RSC 中，仍然在 RSC 中分配条目并缓存该物理文件长度，即使对应表后续在 Replica 节点上不会被访问；后续当 Primary 节点截断表文件时，Replica 节点能够通过缓存值判断是否使用快速算法删除页面