Postgres 9.6：并行查询不采用 max_parallel_workers_per_gather 设置答案

【问题标题】：Postgres 9.6: Parallel query does not take max_parallel_workers_per_gather settingPostgres 9.6：并行查询不采用 max_parallel_workers_per_gather 设置
【发布时间】：2017-07-22 09:45:36
【问题描述】：

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) 为什么“Workers Planned:”只出现在这个设置之后？ 2.2) 为什么我们在使用 max_parallel_workers_per_gather = 5 运行时看不到更好的改进？

谢谢！

【问题讨论】：

你有什么样的硬件？有多少个驱动器？什么类型的驱动器？你的驱动器有多快？那么内存呢？等等。

标签： postgresql parallel-processing explain postgresql-9.6

【解决方案1】：

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

force_parallel_mode（枚举）

允许使用并行查询进行测试，即使在预期没有性能优势的情况。的允许值 force_parallel_mode 关闭（仅在关闭时使用并行模式预计会提高性能），开（强制并行查询所有被认为是安全的查询）和回归（如 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)

【讨论】：

【解决方案2】：

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

由于您没有发布 EXPLAIN ANALYZE 输出，我们无法看到您的查询产生了多少组，但我猜这是一个相当大的数字。在 PostgreSQL 9.6 中，必须通过聚合每个 worker 中的一部分数据（PartialAggregate）然后合并领导者中具有相同键的组（FinalizeAggregate）来执行并行聚合。在这两个步骤之间，需要一个 Gather 节点将部分分组的数据从工作人员传输到领导者。这个 Gather 节点有点贵，所以你看到加速有限的最可能的原因是被传输的组的数量很大。发送所有这些组以及合并发生在多个工作人员中的组的成本可能看起来太高，无法证明具有更多工作人员的并行性是合理的，但对于较少数量的工作人员来说可能看起来像是一场胜利。这些相同的成本可能是因为即使使用并行查询，您也只能看到 25% 的加速。

如果您发布带有和不带有并行查询的 EXPLAIN ANALYZE 输出（即，带有“Workers Planned: 5”并且没有并行性），则可能会更清楚地了解您的情况发生了什么。

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

【讨论】：