为何语句4个多小时没跑出来？调个参数十几分钟立马出来

先上语句
insert into t_gbcp select *
   from (select '20251119'     as date_v     
                ,a.user_id 
                ,a.serial_number                                   -- 用户号码
                ,a.update_date                                     -- 导入时间
                ,a.target_cust_marker_id                           -- 导入标签编码
                ,a.target_cust_marker_name                         -- 导入标签名称
                ,a.start_date                                      -- 标签生效时间
                ,a.end_date                                        -- 标签失效时间
                ,case when a.status in ('1', '2') or a.import_batch_no is null or d.appr_result = '2' then 1
                      else 0 end as is_target_pass   -- 标签是否通过
                ,a.create_date
                ,a.done_date
                ,a.status
                ,a.import_batch_no
        from test1  a
             left join test2 b
               on a.user_id=b.user_id
             left join test3 c
               on a.user_id=c.user_id
             left join test5 d
               on a.import_batch_no=d.import_batch_no
        where a.end_date >= '20250819000000') aa   -- 20250819三个月前
   where aa.is_target_pass = '1'
   and   not exists (select 1
                    from test4 bb 
                    where aa.user_id=bb.user_id 
                    and   aa.target_cust_marker_id=bb.target_cust_marker_id
                    and   aa.update_date=bb.update_date
                    and   aa.start_date=bb.start_date
                    and   aa.end_date=bb.end_date);

语句运行了4个小时，还没出来结果，语句也不复杂。首先我们看一下trace

语句很慢，卡在这个地方，通过说明发现需要物化差不多3000万数据到单个节点，显然中间结果集较大。在看一下执行计划

关联表的顺序，发现a和b和c关联的结果被d表影响，导致中间结果根据d表的分布键进行了重分布。实际上d表数据量不算很大，不到600万，完全把d表拉成复制表，中间结果就不需要重分布。而发现gcluster_hash_redist_threshold_row只有5000000的值。解决办法，把gcluster_hash_redist_threshold_row值调大，最终运行4个小时的语句，18分钟完成。

修改参数后，执行计划和运行结果如下：