HashAggregate VS sort+GroupAgg

  • 时间:
  • 浏览:2

如图:下面是通过颜色分组,有之前 计算sum。

从现在的难题看来,hashagg和groupagg的速度单位还是和一点因素相关的,一般情况表下hashagg的速度单位要更高。在改写count(distinct ...)这类语句是要看值的选择性是就有很高。

大次责情况表下hashagg的速度单位就有比groupagg要好,主假使 sort一种生活操作比较耗时,本质上hashagg是在用空间(内存)换时间,内存丰富的情况表下一种生活做ok,内存不足英文是容易oom(pg在内存不足英文的情况表下是会强制走groupagg)

还可不可不里能看一遍在组个数在10^7以下时,hashagg就有比groupagg优。其中hashagg的耗时也是跟着组个数逐渐升高的。当值达到10^8 时,执行计划会强制走groupagg,即使关闭了enable_sort.

特点是不需用进行排序,在组数值比较小的情况表下是比GroupAggregate要快好多好多 ,有之前 需求的内存会比较多。非要进行一点简单的聚合,像count(distinct ...)这类聚合是做不了的。

参考链接1

参看链接2

GroupAggregatede 特点是在进行聚合之前 不难 将数据进行排序,有之前 进行聚合操作,有之前 出来的结果是有序的。(postgresql使用enable_sort控制)

走了hashagg之前 时间并不难 减少,why?根据上方的理论,时间应该减少才对,仔细看执行计划,时间上改写之前 的语句进行了两次的hashagg,每次时间在4s左右。有之前 第一次hashagg之前 ,可能性amount一种生活值的选择度太高,由于上方一次的hashagg数据量还是和前面一样,好多好多 时间也用了4s左右。好多好多 一种生活改写土方法适合在amount选择度较低的之前 ,减少第二次的hashagg的时间。可能性值选择性很高,原语句和耗时数有俩个多sort+groupagg,改写之前 的语句是2*hashagg。下面亲们 把amount的选择度降低,再来看一下效果。



表t1

还可不可不里能看一遍amount值选择度变低之前 ,第一次hashagg的时间还是4s左右,有之前 第二次hashagg的时间明显减少了,所有改写之前 的语句耗需用比原语句少

应该尽量将groupagg转化为hashagg执行,大次责情况表下执行器会自行选择最优算法,但在一点特定情况表下,需用手动改写。

现在需用转化为hashagg语句,强制关闭sort,发现执行计划还是不难 改变,事实是hashagg无法正确处理count(distinct ...)这类聚合

修改语句

;

利用pg10并行,原语句是无法使用并行的,修改后的语句还可不可不里能走并行,这里亲们 把并行度设置为4,开了并行之前 默认是走sort+groupagg的执行计划

SQL