HashAggregate VS sort+GroupAgg

  • 时间:
  • 浏览:0
  • 来源:uu快3登入_uu快3漏洞_是真的吗

走了hashagg以后 时间并太难 减少,why?根据底下的理论,时间应该减少才对,仔细看执行计划,时间上改写以后 的一句话进行了两次的hashagg,每次时间在4s左右。或者第一次hashagg以后 ,机会amount你你这人值的选取 度太高,是因为底下一次的hashagg数据量还是和前面一样,所以 时间也用了4s左右。所以 你你这人改写妙招 适合在amount选取 度较低的以后 ,减少第二次的hashagg的时间。机会值选取 性很高,原一句话和耗时数另另三个 sort+groupagg,改写以后 的一句话是2*hashagg。下面大伙把amount的选取 度降低,再来看一下效果。

现在我越多 转化为hashagg一句话,强制关闭sort,发现执行计划还是太难 改变,事实是hashagg无法解决count(distinct ...)累似 聚合

表t1

参考链接1

参看链接2



从现在的疑问看来,hashagg和groupagg的强度单位还是和有些因素相关的,一般情形下hashagg的强度单位要更高。在改写count(distinct ...)累似 一句话是要看值的选取 性是有的是很高。

;

SQL

可不我越多 看完amount值选取 度变低以后 ,第一次hashagg的时间还是4s左右,或者第二次hashagg的时间明显减少了,所有改写以后 的一句话耗我越多 比原一句话少

特点是不我越多 进行排序,在组数值比较小的情形下是比GroupAggregate要快所以 ,或者需求的内存会比较多。非要进行有些简单的聚合,像count(distinct ...)累似 聚合是做不了的。

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

利用pg10并行,原一句话是无法使用并行的,修改后的一句话可不我越多 走并行,这里大伙把并行度设置为4,开了并行以后 默认是走sort+groupagg的执行计划

如图:下面是通过颜色分组,或者计算sum。

大每段情形下hashagg的强度单位都会比groupagg要好,主所以 我sort你你这人操作比较耗时,本质上hashagg是在用空间(内存)换时间,内存宽裕的情形下你你这人做ok,内存存在问题是容易oom(pg在内存存在问题的情形下是会强制走groupagg)

应该尽量将groupagg转化为hashagg执行,大每段情形下执行器会自行选取 最优算法,但在有些特定情形下,我越多 手动改写。

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

修改一句话