Postgres 9.6：并行查询不受max_parallel_workers_per_gather设置限制。

Question

Postgres 9.6; Centos 6.7; 24个核心

BigTable1 包含1,500,000,000行；重量为180GB。

max_worker_processes = 20
max_parallel_workers_per_gather = 12

1) 当运行

EXPLAIN
SELECT
    date_id, id1, id2, id3, id4, topdomain, ftype, SUM(imps), SUM(cls)
FROM BigTable1
WHERE
    date_id BETWEEN 2017021200 AND 2017022400             
    AND date_id BETWEEN 2017020000 AND 2017029999   
GROUP BY
date_id, id1, id2, id3, id4, topdomain, ftype;

为什么没有使用“计划中的工作程序”？

2) 在定义会话时运行相同的查询

set max_parallel_workers_per_gather = 5;

出现“计划工作人员：5”。仅通过25％改善了执行时间。

2.1）为什么只有在此设置后才出现“计划工作人员：”？ 2.2）为什么当使用max_parallel_workers_per_gather = 5运行时，我们看不到更好的改进？

谢谢！

- Anya

---

你有什么样的硬件？有多少驱动器？是什么类型的驱动器？驱动器速度如何？内存呢？等等。 - Frank Heikens

Answer 1

当 PostgreSQL 考虑并行顺序扫描时，它根据关系大小（或驱动表的“parallel_workers”存储参数）决定应使用多少个工作者，并计算具有该数量工作者的并行计划成本。 这与串行计划的成本进行比较，成本更低的计划获胜。 不考虑其他工作者数量的计划，因此串行计划的成本可能低于所考虑的计划的成本，但高于某些不同工作者数量的计划成本。 这在您的情况下可能会发生。

由于您没有发布 EXPLAIN ANALYZE 输出，因此我们无法看到查询生成了多少组，但我猜测这是一个相当大的数字。 在 PostgreSQL 9.6 中，必须通过对每个工作者的一部分数据进行聚合（PartialAggregate）然后在 leader 中合并具有相同键的组来执行并行聚合（ParallelAggregate）。 在这两个步骤之间，需要 Gather 节点将部分分组数据从工作者传输到 leader。 这个 Gather 节点有点昂贵，因此您看到的仅有限的加速的最可能原因是要传输的组数很大。 发送所有这些组以及合并出现在多个工作者中的组的成本可能看起来太高而无法证明更高数量的工作者的并行性，但可能看起来像赢得了较少数量的工作者。 这些相同的成本可能解释了即使使用并行查询，您也仅看到 25％ 的速度提升。

如果您发布 EXPLAIN ANALYZE 输出（带有“计划工作者：5”和没有并行性的输出），可能可以更清楚地了解在您的情况下正在发生什么。

（来源：我是 PostgreSQL 并行查询支持的主要作者之一。）

- Robert Haas

Answer 2

如果您只是想测试并行查询功能，则可以查看force_parallel_mode并将其设置为开启。

force_parallel_mode（枚举）

允许在没有预期获得性能提升的情况下，用于测试目的使用并行查询。force_parallel_mode的允许值包括off（仅在预期提高性能时使用并行模式），on（对于所有认为是安全的查询都强制使用并行查询），和regress（类似于on，但具有下面解释的其他行为更改）。

正如robert-haas所述，没有force_parallel_mode，优化器可能会决定并行查询不是最快的...请参见下面的参数：

select
  name,
  setting,
  unit,
  short_desc
from pg_settings
where name in (
  'force_parallel_mode',
  'min_parallel_relation_size',
  'parallel_setup_cost',
  'parallel_tuble_cost',
  'max_parallel_workers_per_gather' )
  limit 10 ;

---

postgres=> 
---------------------------------+---------+------+---------------------------------------------------------------------------------------------
 force_parallel_mode             | off     |      | Forces use of parallel query facilities.
 max_parallel_workers_per_gather | 0       |      | Sets the maximum number of parallel processes per executor node.
 min_parallel_relation_size      | 1024    | 8kB  | Sets the minimum size of relations to be considered for parallel scan.
 parallel_setup_cost             | 1000    |      | Sets the planner's estimate of the cost of starting up worker processes for parallel query.
(4 rows)

- joefromct