This is an automated email from the ASF dual-hosted git repository.

avamingli pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/cloudberry.git

commit 3706ac29d3ae4bfdda17908a43a5d8a04518c5f0
Author: QingMa <[email protected]>
AuthorDate: Wed Dec 21 17:20:36 2022 +0800

    Remove GPDB_12_MERGE_FIXME in cdb_create_multistage_grouping_paths() 
(#14556)
    
    We used to have the same logic between create_grouping_paths() and
    cdb_create_multistage_grouping_paths() to determine if the input
    is hashable / sortable.
    ```
            can_sort = grouping_is_sortable(parse->groupClause);
            can_hash = (parse->groupClause != NIL &&
                                    agg_costs->numPureOrderedAggs == 0 &&
                                    grouping_is_hashable(parse->groupClause));
    ```
    
    The logic in create_grouping_paths() has been changed by commit
    b5635948ab165b6070e7d05d111f966e07570d81 because if we have
    grouping sets we might be able to sort / hash some but not all
    of them.
    ```
            can_sort = (gd && gd->rollups != NIL)
                    || grouping_is_sortable(parse->groupClause);
            can_hash = (parse->groupClause != NIL &&
                                    parse->groupingSets == NIL &&
                                    agg_costs->numOrderedAggs == 0 &&
                     (gd ? gd->any_hashable : 
grouping_is_hashable(parse->groupClause)));
    ```
    It's not necessary to support multistage grouping sets(unhashable_col, 
unsortable_col).
    Ordinary grouping path can cover such corner cases. So just remove this 
merge fixme.
---
 src/backend/cdb/cdbgroupingpaths.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/backend/cdb/cdbgroupingpaths.c 
b/src/backend/cdb/cdbgroupingpaths.c
index c987044433..4f050433dc 100644
--- a/src/backend/cdb/cdbgroupingpaths.c
+++ b/src/backend/cdb/cdbgroupingpaths.c
@@ -289,11 +289,7 @@ cdb_create_multistage_grouping_paths(PlannerInfo *root,
        /*
         * Is the input hashable / sortable? This is largely the same logic as 
in
         * upstream create_grouping_paths(), but we can do hashing in limited 
ways
-        * even if there are DISTINCT aggs or grouping setst.
-        *
-        * GPDB_12_MERGE:FIXME: the similar rules in planner.c got more 
complicated.
-        * Does this need to be more fine-grained too? See 
GROUPING_CAN_USE_SORT and
-        * GROUPING_CAN_USE_HASH.
+        * even if there are DISTINCT aggs or grouping sets.
         */
        can_sort = grouping_is_sortable(parse->groupClause);
        can_hash = (parse->groupClause != NIL &&


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to