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

谢谢！。

Answer 1

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

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

如果您使用和不使用并行查询发布EXPLAIN ANALYZE输出（即使用＆＃34;计划工作人员：5＆＃34;并且没有并行性），则可能更清楚地了解您的内容情况下。

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

Answer 2

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

force_parallel_mode（enum）

允许使用并行查询进行测试，即使在   预计不会产生任何性能效益的情况。允许的值   force_parallel_mode是关闭的（仅当它是时使用并行模式   预计将提高性能），（强制并行查询所有   查询被认为是安全的，并且回归（比如，但是   其他行为更改，如下所述。）

而且，就像下面提到的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)

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

2 个答案: