PostgreSQL 并行查询

可视化演示

动态演示PostgreSQL并行查询的核心机制，通过采集/分析/决策/反馈四种模式展示关键概念与交互流程。

并行查询原理

晚上八点，餐厅坐满了客人。主厨面前立着一块写满菜单的白板：三十桌都要“什锦大锅菜”，每份要用十种食材。若主厨一个人洗、切、炒、装盘，这道菜可能要四十分钟才上桌。他决定把食材分成三份，叫来三位帮厨同时备料，自己最后把三份半成品倒回大锅一起收汁。这个“先分工、再汇总”的流程，就是并行查询最朴素的模型。

在 PostgreSQL 中，执行一条 SQL 的进程叫 backend（数据库服务进程），它平时就像那位独自干活的主厨。查询优化器首先会形成计划，如果表很大、机器又有空闲 CPU，优化器可能放弃串行计划，改选并行计划：在计划树中插入 Parallel Seq Scan、Parallel Join 等节点，并在最上方放一个 Gather 节点。执行时，多个 worker 进程负责底层扫描和计算，backend 进程通过 Gather 把结果收回来。对用户而言，SQL 没有变，返回的结果集也没有变，只是“后厨团队”变大了。

这并不意味着时间一定缩短为原来的 N 分之一。启动 worker 有固定开销，把结果从各 worker 传回 Gather 也要花时间。用公式看更清楚：

所以并行不是“核越多越快”。只有在 T_s 足够大、能摊薄启动和汇总成本时，请帮厨才划算。这个“划算不划算”的账，后面要讲的优化器代价模型会替我们算。

Worker 进程分配

主厨不可能平时养一百个帮厨在厨房里发呆。接到大单后，他打电话给临时工，菜做完便结账走人。PostgreSQL 中的 parallel worker 就是这样的临时后台进程：查询开始执行时才按需生成，查询结束就退出释放资源。它不是客户端连接，而是多个独立的 postgres 进程，每个 worker 都有自己的执行状态和内存。

分配 worker 时有两层限制。第一层是单个 Gather 节点最多能请几位帮厨，也就是 max_parallel_workers_per_gather；第二层是全库同时在岗的临时工总数，也就是 max_parallel_workers。假如有三个查询同时并行，每个都想请 4 个 worker，但全局池只有 8 个，那么后来的查询可能只拿到更少的 worker，甚至拿不到 worker。这个上限关系可以写成：

后厨不是养了一群吃闲饭的人，而是高峰时临时叫人。DBA 调参数时，只调大单个 Gather 上限可能不够；如果全局池已经被占满，换多少块“招聘启事”都请不到人。

Gather 节点

有了帮厨，还得有一个传菜窗口。帮厨们把做好的半成品端到窗口，主厨站在窗口外面接菜。Gather 节点就是计划树上那扇传菜窗口：它是并行部分与串行部分的分界线，也是唯一把元组（一行行数据）送回主进程的节点。

在 EXPLAIN 输出里，Gather 的下一层通常是 -> Parallel Seq Scan 或 -> Parallel Hash Join。下层节点运行在多个 worker 中，worker 把结果元组放进共享内存队列；Gather 节点从队列里一条条取出，再交给上层节点。对上层而言，仿佛只是从一个普通表扫描读取数据。Gather 只是一个传输管道，它不会偷偷改数据，也不会替你完成 GROUP BY、ORDER BY。若需要聚合，计划会先在 worker 内做 Partial Aggregate（局部聚合），再由 Gather 之上的 Finalize Aggregate（最终聚合）合并。

这个设计让“并行”对上层透明。上层节点不需要知道数据来自 1 个 worker 还是 8 个 worker，只要能不断读到元组就行。这也是为什么 EXPLAIN 中看到 Gather，就基本锁定了并行执行的位置。

并行顺序扫描

全表扫描就像面对一大袋土豆，主厨让帮厨自己从袋子里拿土豆削皮。为了防止两个人削同一颗，帮厨先写一个号码，领走下一段。PostgreSQL 的并行顺序扫描也是这样：表在磁盘上由固定大小的页面组成，worker 通过一个共享的 page range 计数器领取页面区间，领到哪段就扫描哪段。

这种“动态领任务”比把表硬切成 N 份更聪明。如果某个 worker 的磁盘 I/O 特别慢，它只会少领一些区间；快的 worker 会继续领后面的页面，让总进度不会困在某一台“慢厨子”身上。因为页面区间互不重叠，同一行不会被两个 worker 重复扫描。EXPLAIN 中会出现 Parallel Seq Scan on 表名，下面可能还有 Workers Planned: N。

如果串行扫描整张表需要时间 T_{\mathrm{scan}}，那么 N 个 worker 的理想耗时接近：

土豆削得再快，也需要有人把袋子搬进来；T_{\mathrm{setup}} 就是搬袋子的时间。表不够大时，请帮厨反而浪费时间。

并行连接

如果一道菜需要把鸡丁和花生米按编号配对，帮厨不能随便把自己手里的食材丢进同一口锅。A 桌的鸡肉丁要配 A 桌的花生米，B 桌配 B 桌。于是厨房把食材按编号重新分到不同操作台，每个操作台对应一位帮厨，这就是连接键重分布。

在 PostgreSQL 中，最常见的并行连接是 Parallel Hash Join（并行哈希连接）。所有 worker 一起参与构建一张共享哈希表，再并行地拿另一张表的每一行去表中探测。大连接因此不再是单进程慢慢做，而是多个 worker 在共享内存上协作。另一个选项是 Parallel Nested Loop（并行嵌套循环）：外表被并行扫描，内表反复走索引；它的开销通常更高，适合外表大、内表小且有索引的场景。

连接不是免费的。为了让两个输入能被 worker 协同处理，优化器会估算连接后的行数和传输代价，决定使用哪张表作为驱动表，以及是否需要重分布。调优时最常做的动作是：确认连接键是否合适、表统计信息是否新鲜，然后看 EXPLAIN 中并行哈希的构建与探测是否均衡。

配置参数

后厨墙上挂着一张管理制度牌。每个参数都是一条制度：max_parallel_workers_per_gather 控制一个 Gather 最多同时接收几个帮厨的菜，默认是 2；max_parallel_workers 控制全库同时在岗的 worker 总数，默认是 8；min_parallel_table_scan_size 控制低于多大体量的“订单”不叫帮厨，默认是 8MB；parallel_setup_cost 是叫一次帮厨的固定成本，默认是 1000；parallel_tuple_cost 是从 Gather 里端出一行菜的传输成本，默认是 0.1。

优化器不会只看参数，而是把所有代价放上天平。parallel_setup_cost 和 parallel_tuple_cost 是代价模型的一部分，不代表真实毫秒数。想要并行加速，表必须足够大，大到启动成本可以被摊薄。当表大小 S 超过阈值 S_{\min} 时，优化器会按下面的方式粗估可用并行度：

DBA 常做的是先看 EXPLAIN 里的 Workers Planned，如果只有 1，多半是表不够大或代价参数太高；再决定调高 max_parallel_workers_per_gather，还是降低 parallel_setup_cost。修改后执行 SELECT pg_reload_conf(); 让参数生效，不需要重启数据库。

适用与调优

并不是每一道菜都需要叫帮厨。一盘花生米、一碗白米饭，主厨自己顺手就做了；叫三个人反而会挤在灶台前。并行查询最适合分析型 workload：大表聚合、多张大表连接、报表统计、特征计算。短小查询如按主键取一行、小范围索引扫描，串行计划的启动成本更低，优化器自然会选择串行。

以下情况优化器可能放弃并行：表体量低于 min_parallel_table_scan_size；查询调用 PARALLEL UNSAFE 的函数；全局 worker 数不足；单查询被事务或锁资源限制。调优时不要盲目加大 worker 数。先用 EXPLAIN (ANALYZE, BUFFERS) 看执行计划里有没有 Gather、Workers Planned 和 Workers Launched 是否一致，再对比串行计划与并行计划的耗时。若并行后 CPU 没吃满，先看表统计信息和 worker 上限；若 CPU 吃满却更慢，就降低并行度或缩小表扫描范围。

归根结底，并行查询是成本优化器决定的，不是“强制开启”的开关。懂原理的人不会追着最大并行度跑，而是让数据库在正确的 workload 下自己叫来合适的帮厨。

AI 应用场景

Python 演示

import osimport timefrom concurrent.futures import ProcessPoolExecutor  def sim_range(start, end):    total = 0    for i in range(start, end):        total += (i * i) % 97    return total  def run_parallel_scan(n_workers, total_items):    chunk = total_items // n_workers    ranges = []    start = 0    for w in range(n_workers):        end = start + chunk + (1 if w < total_items % n_workers else 0)        ranges.append((start, end))        start = end     with ProcessPoolExecutor(max_workers=n_workers) as pool:        futures = [pool.submit(sim_range, s, e) for s, e in ranges]        return sum(f.result() for f in futures)  if __name__ == "__main__":    items = 2_000_000    t0 = time.perf_counter()    serial = sum((i * i) % 97 for i in range(items))    ts = time.perf_counter() - t0     n = min(os.cpu_count() or 4, 4)    t0 = time.perf_counter()    parallel = run_parallel_scan(n, items)    tp = time.perf_counter() - t0     print(f"serial={serial} parallel={parallel} speedup={ts / tp:.2f}")

1. ProcessPoolExecutor(max_workers=n_workers) as pool相当于主进程临时招募 N 个 worker 进程。
2. pool.submit(sim_range, s, e)把一段下标范围交给一个 worker，类似并行顺序扫描分配页面区间。
3. ranges.append((start, end))预先切好互不重叠的数据区间，保证不会重复计算。
4. sum(f.result() for f in futures)主进程等所有 worker 返回后汇总，这就是一个简易的 Gather。
5. serial = sum((i * i) % 97 for i in range(items))串行基准版本，用来和并行版本对比加速比。
6. speedup={ts / tp:.2f}输出本文公式中的 S(N) = T_s / T_p(N)。

常见误区

面试题