public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tomas Vondra <[email protected]>
Subject: [PATCH 7/7] fix
Date: Thu, 19 Mar 2020 03:02:42 +0100
---
src/backend/executor/nodeAgg.c | 20 ++++++++++----------
src/backend/jit/llvm/llvmjit_expr.c | 2 +-
src/backend/optimizer/plan/planner.c | 12 ++++++------
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executor/nodeAgg.c
index f7b98dd798..51c7f229e2 100644
--- a/src/backend/executor/nodeAgg.c
+++ b/src/backend/executor/nodeAgg.c
@@ -360,7 +360,7 @@ initialize_phase(AggState *aggstate, int newphase)
if (persort->store_in)
{
tuplestore_end(persort->store_in);
- persort->store_in = NULL;
+ persort->store_in = NULL;
}
}
@@ -2017,7 +2017,7 @@ agg_preprocess_groupingsets(AggState *aggstate)
/* Initialize tuples storage for each aggregate phases */
for (phaseidx = 0; phaseidx < aggstate->numphases; phaseidx++)
{
- phase = aggstate->phases[phaseidx];
+ phase = aggstate->phases[phaseidx];
if (!phase->is_hashed)
{
@@ -2039,12 +2039,12 @@ agg_preprocess_groupingsets(AggState *aggstate)
}
else
{
- persort->store_in = tuplestore_begin_heap(false, false, work_mem);
+ persort->store_in = tuplestore_begin_heap(false, false, work_mem);
}
}
else
{
- /*
+ /*
* If it's a AGG_HASHED, we don't need a storage to store
* the tuples for later process, we can do the transition
* immediately.
@@ -2422,7 +2422,7 @@ ExecInitAgg(Agg *node, EState *estate, int eflags)
aggstate->maxsets = numGroupingSets;
aggstate->numphases = 1 + list_length(node->chain);
- /*
+ /*
* We are doing final stage of partial groupingsets, do preprocess
* to input tuples first, redirect the tuples to according aggregate
* phases. See agg_preprocess_groupingsets().
@@ -2431,7 +2431,7 @@ ExecInitAgg(Agg *node, EState *estate, int eflags)
{
aggstate->groupingsets_preprocess = true;
- /*
+ /*
* Allocate gsetid <-> phases mapping, in final stage of
* partial groupingsets, all grouping sets are extracted
* to individual phases, so the number of sets is equal
@@ -2449,7 +2449,7 @@ ExecInitAgg(Agg *node, EState *estate, int eflags)
* agg_sort_input(), this can only happen in groupingsets case.
*/
if (node->sortnode)
- aggstate->input_sorted = false;
+ aggstate->input_sorted = false;
aggstate->aggcontexts = (ExprContext **)
palloc0(sizeof(ExprContext *) * numGroupingSets);
@@ -2626,7 +2626,7 @@ ExecInitAgg(Agg *node, EState *estate, int eflags)
phasedata->setno_gsetids[0] = gs->setId;
}
- /*
+ /*
* Initialize pergroup state. For AGG_HASHED, all groups do transition
* on the fly, all pergroup states are kept in hashtable, everytime
* a tuple is processed, lookup_hash_entry() choose one group and
@@ -2688,7 +2688,7 @@ ExecInitAgg(Agg *node, EState *estate, int eflags)
phasedata->grouped_cols[i] = cols;
phasedata->gset_lengths[i] = current_length;
- /*
+ /*
* In the initial stage of partial grouping sets, it provides extra
* grouping sets ID in the targetlist, fill the setno <-> gsetid
* map, so EEOP_GROUPING_SET_ID can evaluate correct gsetid for
@@ -3871,7 +3871,7 @@ ExecReScanAgg(AggState *node)
}
}
- /*
+ /*
* if the agg is doing final stage of partial groupingsets, reset the
* flag to do groupingsets preprocess again.
*/
diff --git a/src/backend/jit/llvm/llvmjit_expr.c b/src/backend/jit/llvm/llvmjit_expr.c
index f442442269..f70eaabd0c 100644
--- a/src/backend/jit/llvm/llvmjit_expr.c
+++ b/src/backend/jit/llvm/llvmjit_expr.c
@@ -1893,7 +1893,7 @@ llvm_compile_expr(ExprState *state)
v_aggstatep =
LLVMBuildBitCast(b, v_parent, l_ptr(StructAggState), "");
- /*
+ /*
* op->resvalue =
* aggstate->phase->setno_gsetids
* [aggstate->current_set]
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index cedd3e1c9d..a0186091a1 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -4211,7 +4211,7 @@ create_ordinary_grouping_paths(PlannerInfo *root, RelOptInfo *input_rel,
* added to grouped_rel->pathlist. And aggsplit value is not sufficient to
* make a decision.
*/
-static void
+static void
consider_groupingsets_paths(PlannerInfo *root,
RelOptInfo *grouped_rel,
Path *path,
@@ -4601,7 +4601,7 @@ consider_groupingsets_paths(PlannerInfo *root,
}
}
-/*
+/*
* If we are combining the partial groupingsets aggregation, the input is
* mixed with tuples from different grouping sets, executor dispatch the
* tuples to different rollups (phases) according to the grouping set id.
@@ -4644,7 +4644,7 @@ extract_final_rollups(PlannerInfo *root,
{
new_rollup->groupClause = NIL;
new_rollup->gsets_data = list_make1(gs);
- new_rollup->gsets = list_make1(NIL);
+ new_rollup->gsets = list_make1(NIL);
new_rollup->hashable = false;
new_rollup->is_hashed = false;
}
@@ -5364,7 +5364,7 @@ make_partial_grouping_target(PlannerInfo *root,
add_new_columns_to_pathtarget(partial_target, non_group_exprs);
- /*
+ /*
* We are generate partial groupingsets path, add an expression to show
* the grouping set ID for a tuple, so in the final stage, executor can
* know which set this tuple belongs to and combine them.
@@ -6985,7 +6985,7 @@ create_partial_grouping_paths(PlannerInfo *root,
path,
root->group_pathkeys,
-1.0);
-
+
if (parse->hasAggs)
add_partial_path(partially_grouped_rel, (Path *)
create_agg_path(root,
@@ -7059,7 +7059,7 @@ create_partial_grouping_paths(PlannerInfo *root,
AGGSPLIT_INITIAL_SERIAL,
add_partial_path);
}
- else
+ else
{
hashaggtablesize =
estimate_hashagg_tablesize(cheapest_partial_path,
--
2.21.1
--4ms6w442s2ji2wqe--
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected]
Subject: Re: [PATCH 7/7] fix
In-Reply-To: <no-message-id-1882656@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox