文档首页 > > 开发指南> 优化查询性能> 实际调优案例> 案例:调整GUC参数best_agg_plan

案例:调整GUC参数best_agg_plan

分享
更新时间: 2019/06/24 GMT+08:00

现象描述

t1的表定义为:

create table t1(a int, b int, c int) distribute by hash(a);

假设agg下层算子所输出结果集的分布列为setA,agg操作的group by列为setB,则在Stream框架下,Agg操作可以分为两个场景。

  1. setA是setB的一个子集。

    对于这种场景,直接对下层结果集进行汇聚的结果就是正确的汇聚结果,上层算子直接使用即可。如下图所示:

    explain select a, count(1) from t1 group by a;
     id |          operation           | E-rows | E-width | E-costs  
    ----+------------------------------+--------+---------+---------
      1 | ->  Streaming (type: GATHER) |     30 |       4 | 15.56   
      2 |    ->  HashAggregate         |     30 |       4 | 14.31   
      3 |       ->  Seq Scan on t1     |     30 |       4 | 14.14   
    (3 rows)
  2. setA不是setB的一个子集。

    对于这种场景,Stream执行框架分为如下三种计划形态:

    hashagg+gather(redistribute)+hashagg

    redistribute+hashagg(+gather)

    hashagg+redistribute+hashagg(+gather)

    DWS提供了guc参数best_agg_plan来干预执行计划,强制其生成上述对应的执行计划,此参数取值范围为0,1,2,3

    • 取值为1时,强制生成第一种计划。
    • 取值为2时,如果group by列可以重分布,强制生成第二种计划,否则生成第一种计划。
    • 取值为3时,如果group by列可以重分布,强制生成第三种计划,否则生成第一种计划。
    • 取值为0时,优化器会根据以上三种计划的估算代价选择最优的一种计划生成。

    具体影响请看下述图片

    set best_agg_plan to 1;
    SET
    explain select b,count(1) from t1 group by b;
     id |            operation            | E-rows | E-width | E-costs 
    ----+---------------------------------+--------+---------+---------
      1 | ->  HashAggregate               |      8 |       4 | 15.83   
      2 |    ->  Streaming (type: GATHER) |     25 |       4 | 15.83   
      3 |       ->  HashAggregate         |     25 |       4 | 14.33   
      4 |          ->  Seq Scan on t1     |     30 |       4 | 14.14   
    (4 rows)
    set best_agg_plan to 2;
    SET
    explain select b,count(1) from t1 group by b;
     id |                operation                | E-rows | E-width | E-costs 
    ----+-----------------------------------------+--------+---------+---------
      1 | ->  Streaming (type: GATHER)            |     30 |       4 | 15.85   
      2 |    ->  HashAggregate                    |     30 |       4 | 14.60   
      3 |       ->  Streaming(type: REDISTRIBUTE) |     30 |       4 | 14.45   
      4 |          ->  Seq Scan on t1             |     30 |       4 | 14.14   
    (4 rows)
    set best_agg_plan to 3;
    SET
    explain select b,count(1) from t1 group by b;
     id |                operation                | E-rows | E-width | E-costs 
    ----+-----------------------------------------+--------+---------+---------
      1 | ->  Streaming (type: GATHER)            |     30 |       4 | 15.84   
      2 |    ->  HashAggregate                    |     30 |       4 | 14.59   
      3 |       ->  Streaming(type: REDISTRIBUTE) |     25 |       4 | 14.59   
      4 |          ->  HashAggregate              |     25 |       4 | 14.33   
      5 |             ->  Seq Scan on t1          |     30 |       4 | 14.14   
    (5 rows)

优化说明

通常优化器总会选择最优的执行计划,但是众所周知代价估算,尤其是中间结果集的代价估算一般会有比较大的偏差,这种比较大的偏差就可能会导致agg的计算方式出现比较大的偏差,这时候就需要通过best_agg_plan进行agg计算模型的干预。

一般来说,当agg汇聚的收敛度很小时,即结果集的个数在agg之后并没有明显变少时(经验上以5倍为临界点),选择redistribute+hashagg执行方式,否则选择hashagg+redistribute+hashagg执行方式。

分享:

    相关文档

    相关产品

文档是否有解决您的问题?

提交成功!

非常感谢您的反馈,我们会继续努力做到更好!

反馈提交失败,请稍后再试!

*必选

请至少选择或填写一项反馈信息

字符长度不能超过200

提交反馈 取消

如您有其它疑问,您也可以通过华为云社区问答频道来与我们联系探讨

跳转到云社区