Hotdry.
归档
database-systems

PostgreSQL并行查询执行器的工程实现与优化策略

深入分析PostgreSQL并行查询执行器的底层架构，包括worker进程调度机制、数据分区策略、内存屏障同步实现，以及并行度自适应调整的工程化参数。

PostgreSQL 自 9.6 版本引入并行查询功能以来，其执行器架构经历了多次优化迭代。与简单的多线程并行不同，PostgreSQL 采用基于进程的并行模型，通过精心设计的 worker 调度、数据分区和内存同步机制，在保持 ACID 特性的同时实现查询加速。本文将深入剖析这一复杂系统的工程实现细节。

一、Gather 节点与 Worker 进程协作架构

PostgreSQL 并行查询的核心是Gather和Gather Merge节点。当优化器选择并行计划时，会在计划树顶部插入这些节点。Gather节点负责启动和管理 worker 进程，而Gather Merge在并行排序场景下使用，确保结果有序合并。

worker 进程通过动态共享内存（DSM）与 leader 进程通信。每个 worker 执行相同的并行计划片段，但处理不同的数据子集。关键配置参数包括：

  • max_parallel_workers_per_gather：每个 Gather 节点允许的最大 worker 数（默认 2）
  • max_worker_processes：系统允许的最大后台 worker 进程总数（默认 8）
  • max_parallel_workers：专门用于并行查询的 worker 上限（默认 8）

实际 worker 数量由优化器基于成本模型决定，但受上述参数限制。如果可用 worker 不足，查询可能以更少 worker 甚至无 worker（仅 leader）执行。

二、数据分区策略：从表块到索引的并行化

2.1 并行顺序扫描（Parallel Sequential Scan）

这是最基础的并行扫描类型。表的数据块被划分为连续范围，每个 worker 分配一个范围。例如，一个包含 1000 个块的表，如果有 4 个 worker，可能分配如下：

  • Worker 1：块 1-250
  • Worker 2：块 251-500
  • Worker 3：块 501-750
  • Worker 4：块 751-1000

每个 worker 完成自己的范围后，通过共享队列请求更多工作。这种动态负载均衡机制避免了 worker 空闲。

2.2 并行位图堆扫描（Parallel Bitmap Heap Scan）

对于带条件的查询，PostgreSQL 采用两阶段并行策略：

  1. Leader 构建位图：一个 worker 被选为 leader，扫描索引并构建需要访问的堆块位图
  2. Worker 并行扫描：位图确定的堆块被划分为范围，分配给所有 worker（包括 leader）

这种设计的巧妙之处在于，索引扫描本身不并行化（避免锁竞争），但后续的堆扫描可以并行。对于WHERE id > 1000 AND id < 2000这类查询，性能提升显著。

2.3 并行索引扫描（Parallel Index Scan）

目前仅支持 B-tree 索引的并行扫描。worker 轮流读取索引块：每个 worker 声明一个索引块，扫描该块引用的所有元组，然后获取下一个可用块。由于 B-tree 的有序特性，每个 worker 内部的结果保持有序，但全局顺序需要Gather Merge节点合并。

技术实现上，PostgreSQL 使用_bt_parallel_seize函数管理索引块分配，通过原子操作确保块分配的一致性。

三、内存屏障与同步机制

3.1 动态共享内存（DSM）架构

DSM 是 PostgreSQL 并行查询的基石。leader 进程创建 DSM 段，包含：

  • 固定大小区域（FixedParallelState）：包含 spinlock、条件变量等同步原语
  • 表内容（TOC）：存储序列化的后端状态，如 GUC 设置、事务快照、锁组信息

worker 通过dsm_attach附加到 DSM 段，使用shm_toc_lookup按 key 查找所需数据。这种设计避免了进程间频繁的上下文切换开销。

3.2 同步原语实现

  1. Spinlocks：保护 FixedParallelState 等关键数据结构
  2. 共享消息队列（shm_mq）：用于错误报告和状态通信
  3. 条件变量：协调 worker 启动和完成

源代码中的关键函数：

// parallel.c中的同步点
void WaitForParallelWorkersToAttach(ParallelContext *pcxt);
void WaitForParallelWorkersToFinish(ParallelContext *pcxt);

3.3 锁组协调

为避免死锁，所有 worker 加入 leader 的锁组（BecomeLockGroupMember）。这样，当一个 worker 等待锁时，其他 worker 可以代表它获取锁。这种机制在并行更新场景下尤为重要。

四、并行度自适应调整算法

PostgreSQL 的并行度决策基于复杂的成本模型，考虑因素包括：

4.1 成本参数调优

  • parallel_setup_cost：并行启动成本（默认 1000）
  • parallel_tuple_cost：worker 间元组传输成本（默认 0.1）
  • min_parallel_table_scan_size：启用并行扫描的最小表大小（默认 8MB）
  • min_parallel_index_scan_size：启用并行索引扫描的最小索引大小（默认 512KB）

优化器计算并行与串行执行的估计成本，选择成本较低者。调整这些参数可以影响并行决策：

-- 降低并行门槛
SET parallel_setup_cost = 100;
SET parallel_tuple_cost = 0.01;

4.2 自适应调整机制

虽然 PostgreSQL 没有完全的运行时自适应并行度调整，但通过以下机制实现一定程度的自适应：

  1. 基于统计信息的预判：优化器使用reltuples（表元组数估计）和relpages（表页数）决定并行度
  2. 动态 worker 可用性：如果请求的 worker 不可用，查询以较少 worker 执行
  3. 并行追加（Parallel Append）的智能调度：对于分区表，Parallel Append节点将 worker 均匀分配到各分区，即使某些分区没有高效并行计划

4.3 监控与诊断

使用EXPLAIN (ANALYZE, VERBOSE)查看并行执行详情：

EXPLAIN (ANALYZE, VERBOSE) 
SELECT COUNT(*) FROM large_table WHERE created_at > '2025-01-01';

输出包含每个 worker 的执行时间和处理行数，帮助识别负载不均衡问题。

五、工程实践与性能调优

5.1 内存管理注意事项

每个 worker 有自己的work_mem，总内存使用量为：

总内存 ≈ work_mem × (worker数 + 1) + 共享内存开销

对于内存密集型操作（如哈希连接、排序），需要谨慎设置work_mem，避免 OOM。

5.2 并行聚合的局限性

并行聚合采用两阶段策略：

  1. Partial Aggregate：每个 worker 执行部分聚合
  2. Finalize Aggregate：leader 合并部分结果

当聚合组数接近输入行数时（如SELECT DISTINCT），并行聚合可能没有优势，因为 leader 需要处理几乎所有的组。

5.3 最佳实践参数配置

-- 生产环境推荐配置
max_worker_processes = 8;
max_parallel_workers = 8;
max_parallel_workers_per_gather = 4;
parallel_setup_cost = 500;
parallel_tuple_cost = 0.05;
min_parallel_table_scan_size = 1MB;  -- 更积极的并行化

5.4 监控指标

关键监控点：

  • pg_stat_activity中的等待事件：IPC: Parallel Finish、IPC: Execute Gather
  • 共享内存使用情况
  • worker 进程的 CPU 和内存使用率

六、未来发展方向

PostgreSQL 社区正在探索以下改进：

  1. 更细粒度的并行化：支持更多操作类型的并行执行
  2. 运行时自适应并行度：基于实际执行进度动态调整 worker 数
  3. 更好的负载均衡：改进数据分区算法，减少倾斜
  4. 混合并行模型：结合进程和线程的优势

结论

PostgreSQL 的并行查询执行器是一个工程复杂度极高的系统，在进程隔离、内存同步、数据一致性等方面做出了精巧的设计权衡。理解其底层机制不仅有助于性能调优，也为构建高并发数据处理系统提供了宝贵参考。随着硬件核心数的持续增长，并行查询优化将成为数据库性能的关键战场。

资料来源：

  1. PostgreSQL 官方文档：https://postgresql.org/docs/current/parallel-plans.html
  2. PostgreSQL 源代码：https://doxygen.postgresql.org/backend_2access_2transam_2parallel_8c_source.html
查看归档