对于任何需要维护超大表（更新旧数据、分批删除、数据迁移）的 DBA 或开发者来说，使用  ctid （元组物理位置）将大表切分为多个小块进行处理是标准操作。然而，直到现在，这种操作都有一个巨大的痛点： 它严格依赖单进程。

随着最近的一个 Commit ( 0ca3b169 ) 合并入 PostgreSQL 19 (master 分支)， TID 范围扫描（TID Range Scans）终于支持并行了。

根据基准测试，新特性的速度提升高达  3 倍。

1. 核心痛点：规划器（Planner）的权衡

Postgres 自版本 14 起就支持了  TID Range Scans 。这允许你基于物理块号扫描表的特定切片：

SELECT * FROM my_large_table WHERE ctid >= '(0,0)' AND ctid < '(10000,0)';

这是像 AWS DMS 这样的工具或逻辑复制初始化器拆分海量表的标准方式。问题在于，直到现在这种扫描节点严格来说都是 单工作进程（single worker） 的。

这迫使 Postgres 查询规划器陷入了两难境地。当你在大数据集上运行查询时，规划器必须在以下两者之间做出选择：

• TID Range Scan：I/O 高效（只读取你请求的块），但是单工作进程。

• Parallel Seq Scan（并行顺序扫描）：CPU 高效（占用所有 CPU 内核），但 I/O 浪费（可能会为了过滤而读取超出你范围的块）。

规划器经常会错误地选择并行顺序扫描，CPU 收益似乎超过了 I/O 损耗带来的负面影响。这导致数据库为了利用可用的工作进程，读取了比必要多得多的数据。

2. 修复方案：并行性与可变分块

• 大块开始 (Large Start)：工作进程开始时领取大块的块，以最大限度地减少共享状态上的锁定开销。
• 逐渐减小 (Tapering Down)：随着扫描的进行，分块大小会缩小。
• 颗粒化结束 (Granular Finish)：到扫描结束时，工作进程每次只领取 1 个块。

3. 基准测试数据

• 数据量：1000 万行
• 查询： SELECT count(*) FROM bench_tid_range WHERE ctid >= '(0,0)' AND ctid < '(41667,0)'

4. 为什么不直接用“并行顺序扫描”？

• 执行时间：~230 ms。
• I/O：访问了所有 ~83k 个页面。

5. 这对工具意味着什么

如果你维护在 Postgres 实例之间移动数据的内部脚本，你可能编写了手动计算块范围并将巨大的表划分为块、然后生成进程来运行它们的代码。

随着 PostgreSQL 19 的推出，这种复杂性可能可以被删除了。你可以发出更广泛的 TID 范围查询，并相信规划器会有效地在集群的 I/O 和 CPU 资源之间分配工作。

6. 如何复现测试

-- 1. 创建表


DROPTABLEIFEXISTS bench_tid_range;


CREATETABLE bench_tid_range (
id
int, payload 
text);




-- 2. 插入 10M 行以生成 ~41k 个页面


INSERTINTO bench_tid_range


SELECT x, 
'payload_' || x


FROM generate_series(
1, 
10000000) x;




-- 3. Vacuum 以设置可见性映射并冻结（对于稳定的基准测试很重要）

VACUUM (
ANALYZE, FREEZE) bench_tid_range;




-- 4. 为会话启用并行


SET max_parallel_workers_per_gather = 
4; 
-- 尝试 2, 4, 8


SET min_parallel_table_scan_size = 
0;    
-- 即使对于较小的表也强制并行扫描




-- 5. 运行查询


EXPLAIN (
ANALYZE, BUFFERS)


SELECTcount(*)


FROM bench_tid_range


WHERE ctid >= 
'(0,0)'
AND ctid < 
'(41667,0)';

7. 结论

8. 参考