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

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运行时看不到更好的改进？

谢谢！。

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

由于您没有发布EXPLAIN ANALYZE输出，因此我们看不到您的查询正在生成多少个组，但我想这是一个相当大的数目。在PostgreSQL 9.6中，必须通过以下方式执行并行聚合：聚合每个工作程序中的一部分数据（PartialAggregate），然后合并具有领导者中相同键的组（FinalizeAggregate）。在这两个步骤之间，需要一个Gather节点将部分分组的数据从工作人员传输到领导者。这个Gather节点有些昂贵，所以您看到加速有限的最可能的原因是正在传输的组数很大。派遣所有这些组以及发生在多个工人中的合并组的成本可能看起来过高，无法证明与更多工人的并行性是合理的，但看起来工人较少的胜利。这些相同的成本可能导致以下事实：即使使用并行查询，您也只能看到25％的加速。

如果发布带有或不带有并行查询的EXPLAIN ANALYZE输出（即使用“ Workers Planned：5”并且没有并行性），则可能可以更清楚地了解您的情况。

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