1

Postgres 9.6；Centos 6.7 ; 24 核 BigTable1 包含 1,500,000,000 行；重量 180GB。max_worker_processes = 20 max_parallel_workers_per_gather = 12

完成并比较了两个测试：

1) 运行解释分析时，从 BigTable1 中选择 count(*)；

我们有“Workers Planned: 10”，查询执行时间是 448 秒。解释分析输出是：

Parallel Seq Scan on BigTable1 (cost=0.00..20137165.46 rows=**177208946** width=0) (actual time=0.023..417798.820 rows=159481670 loops=10)

我们看到几乎所有的时间都花在读取和统计 BigTable1 中的数据上

2) 当使用定义的 set max_parallel_workers_per_gather = 0 运行相同的查询时；

执行时间为 547 秒。

 Aggregate  (cost=38306668.21..38306668.22 rows=1 width=8) (actual time=547132.254..547132.255 rows=1 loops=1)
   ->  Append  (cost=0.00..34319310.77 rows=1594942978 width=0) (actual time=0.562..444920.155 rows=**1595067208** loops=1) 
        -> Seq Scan on category_data_prt_201702  (cost=0.00..34313881.12 rows=1594880512 width=0) (actual time=0.026..312120.207 rows=1594816703 loops=1)

问题是：

  • 为什么 10 个循环的工作比 1 个循环慢？
  • 没有并行的查询确实花费了时间，即以下含义是什么：
 Aggregate  (cost=38306668.21..38306668.22 rows=1 width=8) (actual time=547132.254..547132.255 rows=1 loops=1)
   ->  Append  (cost=0.00..34319310.77 rows=**1594942978** width=0) (actual time=0.562..444920.155 rows=1595067208 loops=1)
  • 为什么在并行查询执行测试的情况下没有那些“追加/聚合”部分？
4

0 回答 0