diff options
Diffstat (limited to 'src/backend/optimizer/plan/planner.c')
| -rw-r--r-- | src/backend/optimizer/plan/planner.c | 73 |
1 files changed, 37 insertions, 36 deletions
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c index 0508d16902b..0f1e2e46802 100644 --- a/src/backend/optimizer/plan/planner.c +++ b/src/backend/optimizer/plan/planner.c @@ -192,7 +192,7 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams) /* * We document cursor_tuple_fraction as simply being a fraction, which - * means the edge cases 0 and 1 have to be treated specially here. We + * means the edge cases 0 and 1 have to be treated specially here. We * convert 1 to 0 ("all the tuples") and 0 to a very small fraction. */ if (tuple_fraction >= 1.0) @@ -386,7 +386,7 @@ subquery_planner(PlannerGlobal *glob, Query *parse, } /* - * Preprocess RowMark information. We need to do this after subquery + * Preprocess RowMark information. We need to do this after subquery * pullup (so that all non-inherited RTEs are present) and before * inheritance expansion (so that the info is available for * expand_inherited_tables to examine and modify). @@ -506,7 +506,7 @@ subquery_planner(PlannerGlobal *glob, Query *parse, * to execute that we're better off doing it only once per group, despite * the loss of selectivity. This is hard to estimate short of doing the * entire planning process twice, so we use a heuristic: clauses - * containing subplans are left in HAVING. Otherwise, we move or copy the + * containing subplans are left in HAVING. Otherwise, we move or copy the * HAVING clause into WHERE, in hopes of eliminating tuples before * aggregation instead of after. * @@ -916,8 +916,8 @@ inheritance_planner(PlannerInfo *root) subplan = grouping_planner(&subroot, 0.0 /* retrieve all tuples */ ); /* - * Planning may have modified the query result relation (if there - * were security barrier quals on the result RTE). + * Planning may have modified the query result relation (if there were + * security barrier quals on the result RTE). */ appinfo->child_relid = subroot.parse->resultRelation; @@ -940,7 +940,8 @@ inheritance_planner(PlannerInfo *root) else { List *tmp_rtable = NIL; - ListCell *cell1, *cell2; + ListCell *cell1, + *cell2; /* * Check to see if any of the original RTEs were turned into @@ -1108,7 +1109,7 @@ grouping_planner(PlannerInfo *root, double tuple_fraction) /* * If there's a top-level ORDER BY, assume we have to fetch all the - * tuples. This might be too simplistic given all the hackery below + * tuples. This might be too simplistic given all the hackery below * to possibly avoid the sort; but the odds of accurate estimates here * are pretty low anyway. */ @@ -1135,7 +1136,7 @@ grouping_planner(PlannerInfo *root, double tuple_fraction) /* * We should not need to call preprocess_targetlist, since we must be - * in a SELECT query node. Instead, use the targetlist returned by + * in a SELECT query node. Instead, use the targetlist returned by * plan_set_operations (since this tells whether it returned any * resjunk columns!), and transfer any sort key information from the * original tlist. @@ -1152,11 +1153,11 @@ grouping_planner(PlannerInfo *root, double tuple_fraction) if (parse->rowMarks) ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), - /*------ - translator: %s is a SQL row locking clause such as FOR UPDATE */ + /*------ + translator: %s is a SQL row locking clause such as FOR UPDATE */ errmsg("%s is not allowed with UNION/INTERSECT/EXCEPT", LCS_asString(((RowMarkClause *) - linitial(parse->rowMarks))->strength)))); + linitial(parse->rowMarks))->strength)))); /* * Calculate pathkeys that represent result ordering requirements @@ -1279,7 +1280,7 @@ grouping_planner(PlannerInfo *root, double tuple_fraction) /* * Generate the best unsorted and presorted paths for this Query (but - * note there may not be any presorted paths). We also generate (in + * note there may not be any presorted paths). We also generate (in * standard_qp_callback) pathkey representations of the query's sort * clause, distinct clause, etc. */ @@ -1314,7 +1315,7 @@ grouping_planner(PlannerInfo *root, double tuple_fraction) /* * In GROUP BY mode, an absolute LIMIT is relative to the number - * of groups not the number of tuples. If the caller gave us a + * of groups not the number of tuples. If the caller gave us a * fraction, keep it as-is. (In both cases, we are effectively * assuming that all the groups are about the same size.) */ @@ -1673,7 +1674,7 @@ grouping_planner(PlannerInfo *root, double tuple_fraction) * Furthermore, there cannot be any variables in either HAVING * or the targetlist, so we actually do not need the FROM * table at all! We can just throw away the plan-so-far and - * generate a Result node. This is a sufficiently unusual + * generate a Result node. This is a sufficiently unusual * corner case that it's not worth contorting the structure of * this routine to avoid having to generate the plan in the * first place. @@ -1717,14 +1718,14 @@ grouping_planner(PlannerInfo *root, double tuple_fraction) /* * The "base" targetlist for all steps of the windowing process is - * a flat tlist of all Vars and Aggs needed in the result. (In + * a flat tlist of all Vars and Aggs needed in the result. (In * some cases we wouldn't need to propagate all of these all the * way to the top, since they might only be needed as inputs to * WindowFuncs. It's probably not worth trying to optimize that * though.) We also add window partitioning and sorting * expressions to the base tlist, to ensure they're computed only * once at the bottom of the stack (that's critical for volatile - * functions). As we climb up the stack, we'll add outputs for + * functions). As we climb up the stack, we'll add outputs for * the WindowFuncs computed at each level. */ window_tlist = make_windowInputTargetList(root, @@ -1733,7 +1734,7 @@ grouping_planner(PlannerInfo *root, double tuple_fraction) /* * The copyObject steps here are needed to ensure that each plan - * node has a separately modifiable tlist. (XXX wouldn't a + * node has a separately modifiable tlist. (XXX wouldn't a * shallow list copy do for that?) */ result_plan->targetlist = (List *) copyObject(window_tlist); @@ -2018,7 +2019,7 @@ grouping_planner(PlannerInfo *root, double tuple_fraction) * * Once grouping_planner() has applied a general tlist to the topmost * scan/join plan node, any tlist eval cost for added-on nodes should be - * accounted for as we create those nodes. Presently, of the node types we + * accounted for as we create those nodes. Presently, of the node types we * can add on later, only Agg, WindowAgg, and Group project new tlists (the * rest just copy their input tuples) --- so make_agg(), make_windowagg() and * make_group() are responsible for calling this function to account for their @@ -2150,7 +2151,7 @@ preprocess_rowmarks(PlannerInfo *root) * insufficient because of rule substitution, query pullup, etc. */ CheckSelectLocking(parse, ((RowMarkClause *) - linitial(parse->rowMarks))->strength); + linitial(parse->rowMarks))->strength); } else { @@ -2184,7 +2185,7 @@ preprocess_rowmarks(PlannerInfo *root) /* * Currently, it is syntactically impossible to have FOR UPDATE et al - * applied to an update/delete target rel. If that ever becomes + * applied to an update/delete target rel. If that ever becomes * possible, we should drop the target from the PlanRowMark list. */ Assert(rc->rti != parse->resultRelation); @@ -2268,7 +2269,7 @@ preprocess_rowmarks(PlannerInfo *root) * preprocess_limit - do pre-estimation for LIMIT and/or OFFSET clauses * * We try to estimate the values of the LIMIT/OFFSET clauses, and pass the - * results back in *count_est and *offset_est. These variables are set to + * results back in *count_est and *offset_est. These variables are set to * 0 if the corresponding clause is not present, and -1 if it's present * but we couldn't estimate the value for it. (The "0" convention is OK * for OFFSET but a little bit bogus for LIMIT: effectively we estimate @@ -2277,7 +2278,7 @@ preprocess_rowmarks(PlannerInfo *root) * be passed to make_limit, which see if you change this code. * * The return value is the suitably adjusted tuple_fraction to use for - * planning the query. This adjustment is not overridable, since it reflects + * planning the query. This adjustment is not overridable, since it reflects * plan actions that grouping_planner() will certainly take, not assumptions * about context. */ @@ -2401,7 +2402,7 @@ preprocess_limit(PlannerInfo *root, double tuple_fraction, else if (*offset_est != 0 && tuple_fraction > 0.0) { /* - * We have an OFFSET but no LIMIT. This acts entirely differently + * We have an OFFSET but no LIMIT. This acts entirely differently * from the LIMIT case: here, we need to increase rather than decrease * the caller's tuple_fraction, because the OFFSET acts to cause more * tuples to be fetched instead of fewer. This only matters if we got @@ -2416,7 +2417,7 @@ preprocess_limit(PlannerInfo *root, double tuple_fraction, /* * If we have absolute counts from both caller and OFFSET, add them - * together; likewise if they are both fractional. If one is + * together; likewise if they are both fractional. If one is * fractional and the other absolute, we want to take the larger, and * we heuristically assume that's the fractional one. */ @@ -2457,7 +2458,7 @@ preprocess_limit(PlannerInfo *root, double tuple_fraction, * * If we have constant-zero OFFSET and constant-null LIMIT, we can skip adding * a Limit node. This is worth checking for because "OFFSET 0" is a common - * locution for an optimization fence. (Because other places in the planner + * locution for an optimization fence. (Because other places in the planner * merely check whether parse->limitOffset isn't NULL, it will still work as * an optimization fence --- we're just suppressing unnecessary run-time * overhead.) @@ -2700,7 +2701,7 @@ choose_hashed_grouping(PlannerInfo *root, /* * Executor doesn't support hashed aggregation with DISTINCT or ORDER BY - * aggregates. (Doing so would imply storing *all* the input values in + * aggregates. (Doing so would imply storing *all* the input values in * the hash table, and/or running many sorts in parallel, either of which * seems like a certain loser.) We similarly don't support ordered-set * aggregates in hashed aggregation, but that case is included in the @@ -2840,7 +2841,7 @@ choose_hashed_grouping(PlannerInfo *root, * pass in the costs as individual variables.) * * But note that making the two choices independently is a bit bogus in - * itself. If the two could be combined into a single choice operation + * itself. If the two could be combined into a single choice operation * it'd probably be better, but that seems far too unwieldy to be practical, * especially considering that the combination of GROUP BY and DISTINCT * isn't very common in real queries. By separating them, we are giving @@ -2937,7 +2938,7 @@ choose_hashed_distinct(PlannerInfo *root, 0.0, work_mem, limit_tuples); /* - * Now for the GROUP case. See comments in grouping_planner about the + * Now for the GROUP case. See comments in grouping_planner about the * sorting choices here --- this code should match that code. */ sorted_p.startup_cost = sorted_startup_cost; @@ -3127,7 +3128,7 @@ make_subplanTargetList(PlannerInfo *root, * add them to the result tlist if not already present. (A Var used * directly as a GROUP BY item will be present already.) Note this * includes Vars used in resjunk items, so we are covering the needs of - * ORDER BY and window specifications. Vars used within Aggrefs will be + * ORDER BY and window specifications. Vars used within Aggrefs will be * pulled out here, too. */ non_group_vars = pull_var_clause((Node *) non_group_cols, @@ -3178,7 +3179,7 @@ get_grouping_column_index(Query *parse, TargetEntry *tle) * Locate grouping columns in the tlist chosen by create_plan. * * This is only needed if we don't use the sub_tlist chosen by - * make_subplanTargetList. We have to forget the column indexes found + * make_subplanTargetList. We have to forget the column indexes found * by that routine and re-locate the grouping exprs in the real sub_tlist. * We assume the grouping exprs are just Vars (see make_subplanTargetList). */ @@ -3209,11 +3210,11 @@ locate_grouping_columns(PlannerInfo *root, /* * The grouping column returned by create_plan might not have the same - * typmod as the original Var. (This can happen in cases where a + * typmod as the original Var. (This can happen in cases where a * set-returning function has been inlined, so that we now have more * knowledge about what it returns than we did when the original Var * was created.) So we can't use tlist_member() to search the tlist; - * instead use tlist_member_match_var. For safety, still check that + * instead use tlist_member_match_var. For safety, still check that * the vartype matches. */ if (!(groupexpr && IsA(groupexpr, Var))) @@ -3339,7 +3340,7 @@ select_active_windows(PlannerInfo *root, WindowFuncLists *wflists) * * When grouping_planner inserts one or more WindowAgg nodes into the plan, * this function computes the initial target list to be computed by the node - * just below the first WindowAgg. This list must contain all values needed + * just below the first WindowAgg. This list must contain all values needed * to evaluate the window functions, compute the final target list, and * perform any required final sort step. If multiple WindowAggs are needed, * each intermediate one adds its window function results onto this tlist; @@ -3347,7 +3348,7 @@ select_active_windows(PlannerInfo *root, WindowFuncLists *wflists) * * This function is much like make_subplanTargetList, though not quite enough * like it to share code. As in that function, we flatten most expressions - * into their component variables. But we do not want to flatten window + * into their component variables. But we do not want to flatten window * PARTITION BY/ORDER BY clauses, since that might result in multiple * evaluations of them, which would be bad (possibly even resulting in * inconsistent answers, if they contain volatile functions). Also, we must @@ -3520,7 +3521,7 @@ make_pathkeys_for_window(PlannerInfo *root, WindowClause *wc, * This depends on the behavior of make_pathkeys_for_window()! * * We are given the target WindowClause and an array of the input column - * numbers associated with the resulting pathkeys. In the easy case, there + * numbers associated with the resulting pathkeys. In the easy case, there * are the same number of pathkey columns as partitioning + ordering columns * and we just have to copy some data around. However, it's possible that * some of the original partitioning + ordering columns were eliminated as @@ -3532,7 +3533,7 @@ make_pathkeys_for_window(PlannerInfo *root, WindowClause *wc, * determine which keys are significant. * * The method used here is a bit brute-force: add the sort columns to a list - * one at a time and note when the resulting pathkey list gets longer. But + * one at a time and note when the resulting pathkey list gets longer. But * it's a sufficiently uncommon case that a faster way doesn't seem worth * the amount of code refactoring that'd be needed. *---------- |