卧龙居翻译
PostgreSQL 并行查询
PostgreSQL 可以制定哪些 SQL 可以并行利用 CPU 的查询规划,用于增快 SQL 查询的响应速
度。这个特性以并行查询而为大众所知。有些查询不能够从并行查询之中获益,要么受限于
当前的实现,要么由于并行查询并不比串行查询规划快。然而,对于那些可以从并行查询中
收益的查询而言,并行查询加速的效果是非常明显的。有些查询可以在并行查询中快两倍,
有些查询可以快四倍甚至更多。那些访问大量数据,却返回给用户很少行数的查询是并行查
询效果收益最明显的(译者注:例如统计型查询)。本章介绍了并行查询如何工作的细节,
以及它适用于哪些场景,因此用户可以了解到如何使用它。
15.1 并行查询如何工作
当优化器意识对于一个特定的查询语句并行查询速度更快,它将会创建一个包括聚集节点的
执行规划。这有一个简单示例:
在所有场景下,聚集节点只会有一个子规划,它是查询规划的一部分并且会被并行执行。如
果聚集节点是在规划树的顶部,那么整个查询将会被并行执行。如果它在规划树的其他部分,
那么查询就只有一部分会被并行执行。在上面示例的这个查询中,由于这个查询只访问了一
张表,所以除了聚集节点外就只有一个规划节点,因为规划节点是聚集节点的子节点,所以
它将会被并行执行。
使用 explain,你将可以看到规划器选择了多少个 worker。当在查询执行中访问到聚集节点
时,将会申请和规划器选择的 worker 数目一样多的后台工作进程。在任何时刻后台可以存
在的 worker 的个数是由 max_worker_processes 参数限制的,所以并行的运行一系列的查询
同少量的 worker 甚至有的查询是没有 worker 在一起是可行的。优化策略取决于当前还有多
少 worker 可用,所以它可能会导致比较糟糕的执行效果。如果并行查询是频繁的,那么提
升 max_worker_processes 的 值 让 更 多 worker 可 以 同 时 执 行 , 或 者 有选择的 降低
max_parallel_workers_per_gather 的值使得一个规划器能够获取的 worker 数目降低。
由一个给定的并行查询启动的每个后台工作进程将会执行查询的一部分(这些部分都是聚集
节点的后继节点)。leader 也会执行查询的一部分,但它有附加的任务:读取由 worker 产生
的所有元组。如果规划的并行部分输出少量的元组,那么 leader 更像一个附加的工作节点,
加快查询速度。与之相对的,如果规划的并行部分产生了大量的元组,那么 leader 将会更
多的整个用于处理由工作节点产生的元组,以及执行由聚集节点的上层规划节点指定的处理
任务。在此场景下,leader 只会做规划中并行部分的少部分工作。