postgresql - Postgres 9.6 : Parallel query does not take max_parallel_workers_per_gather setting

Question

Postgres 9.6；中心 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;

根本没有使用“Workers Planned:”。为什么？

2)在定义的 session 中运行相同的查询时

set max_parallel_workers_per_gather = 5;

出现“计划 worker :5”。执行时间仅缩短了 25%。

2.1) 为什么“Workers Planned:”只出现在这个设置之后？2.2) 为什么我们在运行 max_parallel_workers_per_gather = 5 时看不到更好的改进？

谢谢!

Answer 1

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

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

如果您在使用和不使用并行查询的情况下发布 EXPLAIN ANALYZE 输出(即使用“Workers Planned: 5”并且没有并行性)，则可能会更清楚地了解您的情况。

(来源:我是 PostgreSQL 并行查询支持的主要作者之一。)