mirror of
https://github.com/postgres/postgres.git
synced 2025-07-14 08:21:07 +03:00
pgindent run for 9.4
This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
This commit is contained in:
Bruce Momjian
@ -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.
|
||||
*----------
|
||||
|
||||
Reference in New Issue
Block a user