瀚高硬核助力 PG 社区：Postgres 19 迎来并行 TID 范围扫描，速度提升 3 倍

关注

原创 2025-12-15 08:54:10 705 阅读 AI 写同款· GEO 优化 ›

运放+三极管构建LED恒流驱动电路：原理、设计与调试全解析在电子工程领域，恒流源是一种能够提供稳定输出电流的电路，其核心原理基于负反馈控制机制。通过将输出电流采样转化为电压信号，并与一个稳定的参考电压进行比较，系统自动调节功率器件的导通状态，从而抵消输入电压波动或负载变化带来的影响，实现电流恒定。这种技术对于驱动LED、激光二极管等电流敏感型器件具有重要价值，能确保亮度、色温的一致性，并延长器件寿命。本文以经典的运放结合三极管方案为例，深入剖析其如何实现精准的电流“钳位”。该方案利用通用运算放大器作为比较器，配合三极管构成调整管，通过采样电阻实时监测电流，形成了一阅读详情

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

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

该功能由IvorySQL 社区的 Cary Huang 提出并主导开发，由微软的 David Rowley 协助测试及审阅，并最终提交。他们密切合作以完善并行安全逻辑，确保工作进程正确处理扫描限制——最终促成了这个落地到 master 分支的健壮实现。

瀚高以“用开源链接世界”为使命，强调开源技术在数据库基础软件领域的核心作用，致力于通过共享和合作，推动行业发展，同时链接和赋能全球用户。开源技术是中国软件技术发展的必由之路，瀚高作为亚太地区 PostgreSQL 国际社区顶级贡献者之一，长期深度参与 PostgreSQL 国际社区发展与建设。自 2025 年 7 月以来，瀚高被 PostgreSQL 社区采纳的贡献就已超过 2000 行代码。

根据基准测试，新特性的速度提升高达 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. 修复方案：并行性与可变分块

由 Cary Huang 开发并由 David Rowley 提交的代码，引入了允许 Tid Range Scan 参与并行查询计划的基础架构。该逻辑有效地将块范围分配给可用的并行工作进程。不再是一个进程从块 0 扫描到 N，多个工作进程可以并发地获取数据块。

实现（约 500 行代码）重用了并行顺序扫描中的“块分块（block chunking）”逻辑。但它不仅仅是将块范围平均分配给工作进程，因为如果表的某个部分数据密度更高，这种简单分配可能导致负载不均衡。

相反，它使用了衰减块大小策略 (decaying chunk size strategy)：

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

这种“缓慢减少”确保了我们不会最后只剩下一个工作进程在处理一个巨大的最终块，而其他工作进程却闲置着。它强制所有进程大致在同一时间跨过终点线。

3. 基准测试数据

为了看到实际效果，我创建了一个包含 1000 万行的表 bench_tid_range，并使用 ctid 范围条件对表的前 50% 运行了 count(*) 查询。

测试环境：

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

环境	工作进程数 (Workers)	执行时间 (中位数)	加速比
Before (Pg 18)	0	448 ms	1.00x
After (Pg 19)	0	435 ms	1.03x
After (Pg 19)	1	238 ms	1.88x
After (Pg 19)	2	174 ms	2.58x
After (Pg 19)	3	151 ms	2.97x
After (Pg 19)	4	150 ms	2.98x
After (Pg 19)	5	147 ms	3.05x
After (Pg 19)	6	143 ms	3.14x
After (Pg 19)	7	147 ms	3.04x
After (Pg 19)	8	147 ms	3.04x

我们可以看到，仅仅启用 1 个工作进程（这实际上给了我们 2 个扫描进程：Leader + 1 个 Worker），执行时间就大幅下降。对于这个特定的工作负载，“最佳平衡点”似乎在 2-3 个工作进程左右。

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

你可能会问：“为什么 Postgres v18 不直接选择并行顺序扫描？用 4 个工作进程扫描整个表难道不比用 1 个进程扫描半个表快吗？”

我通过强制设置 enable_tidscan = off 并使用 4 个工作进程测试了这一点：

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

新的并行 TID 范围扫描（~150 ms）仍然比暴力/强制的并行顺序扫描快 35%，而且它产生的 I/O 负载只有后者的一半（只访问了 ~41k 个页面）。这可谓两全其美：快速的执行时间（并行）和高效的资源使用（类似索引的范围界定）。

5. 这对工具意味着什么

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

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

6. 如何复现测试

这是设置测试表和运行基准测试的 SQL：

-- 1. 创建表 DROP TABLE IF EXISTS bench_tid_range; CREATE TABLE bench_tid_range (id int, payload text); -- 2. 插入 10M 行以生成 ~41k 个页面 INSERT INTO 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) SELECT count(*) FROM bench_tid_range WHERE ctid >= '(0,0)' AND ctid < '(41667,0)';