Revert "Use CP_SMALL_TLIST for hash aggregate"

This reverts commit 4cad2534da due to a
performance regression. It will be replaced by a new approach in an
upcoming commit.

Reported-by: Andres Freund
Discussion: https://postgr.es/m/20200614181418.mx4bvljmfkkhoqzl@alap3.anarazel.de
Backpatch-through: 13

contrib/postgres_fdw/expected/postgres_fdw.out

@@ -2715,7 +2715,7 @@ select sum(c1) from ft1 group by c2 having avg(c1 * (random() <= 1)::int) > 100
          Group Key: ft1.c2
          Filter: (avg((ft1.c1 * ((random() <= '1'::double precision))::integer)) > '100'::numeric)
          ->  Foreign Scan on public.ft1
-               Output: c2, c1
+               Output: c1, c2
                Remote SQL: SELECT "C 1", c2 FROM "S 1"."T 1"
 (10 rows)
 
@@ -2964,7 +2964,7 @@ select sum(c1) filter (where (c1 / c1) * random() <= 1) from ft1 group by c2 ord
          Output: sum(c1) FILTER (WHERE ((((c1 / c1))::double precision * random()) <= '1'::double precision)), c2
          Group Key: ft1.c2
          ->  Foreign Scan on public.ft1
-               Output: c2, c1
+               Output: c1, c2
                Remote SQL: SELECT "C 1", c2 FROM "S 1"."T 1"
 (9 rows)
 

src/backend/optimizer/plan/createplan.c

@@ -2113,22 +2113,12 @@ create_agg_plan(PlannerInfo *root, AggPath *best_path)
 	Plan	   *subplan;
 	List	   *tlist;
 	List	   *quals;
-	int			flags;
 
 	/*
 	 * Agg can project, so no need to be terribly picky about child tlist, but
-	 * we do need grouping columns to be available. We are a bit more careful
-	 * with hash aggregate, where we explicitly request small tlist to
-	 * minimize I/O needed for spilling (we can't be sure spilling won't be
-	 * necessary, so we just do it every time).
+	 * we do need grouping columns to be available
 	 */
-	flags = CP_LABEL_TLIST;
-
-	/* ensure small tlist for hash aggregate */
-	if (best_path->aggstrategy == AGG_HASHED)
-		flags |= CP_SMALL_TLIST;
-
-	subplan = create_plan_recurse(root, best_path->subpath, flags);
+	subplan = create_plan_recurse(root, best_path->subpath, CP_LABEL_TLIST);
 
 	tlist = build_path_tlist(root, &best_path->path);
 
@@ -2210,7 +2200,6 @@ create_groupingsets_plan(PlannerInfo *root, GroupingSetsPath *best_path)
 	int			maxref;
 	List	   *chain;
 	ListCell   *lc;
-	int			flags;
 
 	/* Shouldn't get here without grouping sets */
 	Assert(root->parse->groupingSets);
@@ -2218,18 +2207,9 @@ create_groupingsets_plan(PlannerInfo *root, GroupingSetsPath *best_path)
 
 	/*
 	 * Agg can project, so no need to be terribly picky about child tlist, but
-	 * we do need grouping columns to be available. We are a bit more careful
-	 * with hash aggregate, where we explicitly request small tlist to
-	 * minimize I/O needed for spilling (we can't be sure spilling won't be
-	 * necessary, so we just do it every time).
+	 * we do need grouping columns to be available
 	 */
-	flags = CP_LABEL_TLIST;
-
-	/* ensure small tlist for hash aggregate */
-	if (best_path->aggstrategy == AGG_HASHED)
-		flags |= CP_SMALL_TLIST;
-
-	subplan = create_plan_recurse(root, best_path->subpath, flags);
+	subplan = create_plan_recurse(root, best_path->subpath, CP_LABEL_TLIST);
 
 	/*
 	 * Compute the mapping from tleSortGroupRef to column index in the child's