diff options
Diffstat (limited to 'src/backend/optimizer/plan/createplan.c')
| -rw-r--r-- | src/backend/optimizer/plan/createplan.c | 32 |
1 files changed, 16 insertions, 16 deletions
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c index e791f20dc12..c246468c929 100644 --- a/src/backend/optimizer/plan/createplan.c +++ b/src/backend/optimizer/plan/createplan.c @@ -168,7 +168,7 @@ static Material *make_material(Plan *lefttree); /* * create_plan * Creates the access plan for a query by recursively processing the - * desired tree of pathnodes, starting at the node 'best_path'. For + * desired tree of pathnodes, starting at the node 'best_path'. For * every pathnode found, we create a corresponding plan node containing * appropriate id, target list, and qualification information. * @@ -282,7 +282,7 @@ create_scan_plan(PlannerInfo *root, Path *best_path) /* * For table scans, rather than using the relation targetlist (which is * only those Vars actually needed by the query), we prefer to generate a - * tlist containing all Vars in order. This will allow the executor to + * tlist containing all Vars in order. This will allow the executor to * optimize away projection of the table tuples, if possible. (Note that * planner.c may replace the tlist we generate here, forcing projection to * occur.) @@ -480,7 +480,7 @@ use_physical_tlist(PlannerInfo *root, RelOptInfo *rel) * * If the plan node immediately above a scan would prefer to get only * needed Vars and not a physical tlist, it must call this routine to - * undo the decision made by use_physical_tlist(). Currently, Hash, Sort, + * undo the decision made by use_physical_tlist(). Currently, Hash, Sort, * and Material nodes want this, so they don't have to store useless columns. */ static void @@ -610,7 +610,7 @@ create_join_plan(PlannerInfo *root, JoinPath *best_path) /* * * Expensive function pullups may have pulled local predicates * into - * this path node. Put them in the qpqual of the plan node. * JMH, + * this path node. Put them in the qpqual of the plan node. * JMH, * 6/15/92 */ if (get_loc_restrictinfo(best_path) != NIL) @@ -639,7 +639,7 @@ create_append_plan(PlannerInfo *root, AppendPath *best_path) /* * It is possible for the subplans list to contain only one entry, or even - * no entries. Handle these cases specially. + * no entries. Handle these cases specially. * * XXX ideally, if there's just one entry, we'd not bother to generate an * Append node but just return the single child. At the moment this does @@ -1298,7 +1298,7 @@ create_bitmap_scan_plan(PlannerInfo *root, /* * When dealing with special operators, we will at this point have - * duplicate clauses in qpqual and bitmapqualorig. We may as well drop + * duplicate clauses in qpqual and bitmapqualorig. We may as well drop * 'em from bitmapqualorig, since there's no point in making the tests * twice. */ @@ -1388,7 +1388,7 @@ create_bitmap_subplan(PlannerInfo *root, Path *bitmapqual, /* * Here, we only detect qual-free subplans. A qual-free subplan would * cause us to generate "... OR true ..." which we may as well reduce - * to just "true". We do not try to eliminate redundant subclauses + * to just "true". We do not try to eliminate redundant subclauses * because (a) it's not as likely as in the AND case, and (b) we might * well be working with hundreds or even thousands of OR conditions, * perhaps from a long IN list. The performance of list_append_unique @@ -1478,7 +1478,7 @@ create_bitmap_subplan(PlannerInfo *root, Path *bitmapqual, /* * We know that the index predicate must have been implied by the * query condition as a whole, but it may or may not be implied by - * the conditions that got pushed into the bitmapqual. Avoid + * the conditions that got pushed into the bitmapqual. Avoid * generating redundant conditions. */ if (!predicate_implied_by(list_make1(pred), ipath->indexclauses)) @@ -2572,7 +2572,7 @@ fix_indexqual_references(PlannerInfo *root, IndexPath *index_path, * * This is a simplified version of fix_indexqual_references. The input does * not have RestrictInfo nodes, and we assume that indxqual.c already - * commuted the clauses to put the index keys on the left. Also, we don't + * commuted the clauses to put the index keys on the left. Also, we don't * bother to support any cases except simple OpExprs, since nothing else * is allowed for ordering operators. */ @@ -2809,7 +2809,7 @@ order_qual_clauses(PlannerInfo *root, List *clauses) /* * Sort. We don't use qsort() because it's not guaranteed stable for - * equal keys. The expected number of entries is small enough that a + * equal keys. The expected number of entries is small enough that a * simple insertion sort should be good enough. */ for (i = 1; i < nitems; i++) @@ -3434,7 +3434,7 @@ make_sort(PlannerInfo *root, Plan *lefttree, int numCols, * prepare_sort_from_pathkeys * Prepare to sort according to given pathkeys * - * This is used to set up for both Sort and MergeAppend nodes. It calculates + * This is used to set up for both Sort and MergeAppend nodes. It calculates * the executor's representation of the sort key information, and adjusts the * plan targetlist if needed to add resjunk sort columns. * @@ -3447,7 +3447,7 @@ make_sort(PlannerInfo *root, Plan *lefttree, int numCols, * * We must convert the pathkey information into arrays of sort key column * numbers, sort operator OIDs, collation OIDs, and nulls-first flags, - * which is the representation the executor wants. These are returned into + * which is the representation the executor wants. These are returned into * the output parameters *p_numsortkeys etc. * * When looking for matches to an EquivalenceClass's members, we will only @@ -3890,7 +3890,7 @@ make_material(Plan *lefttree) * materialize_finished_plan: stick a Material node atop a completed plan * * There are a couple of places where we want to attach a Material node - * after completion of subquery_planner(). This currently requires hackery. + * after completion of subquery_planner(). This currently requires hackery. * Since subquery_planner has already run SS_finalize_plan on the subplan * tree, we have to kluge up parameter lists for the Material node. * Possibly this could be fixed by postponing SS_finalize_plan processing @@ -4106,7 +4106,7 @@ make_group(PlannerInfo *root, /* * distinctList is a list of SortGroupClauses, identifying the targetlist items - * that should be considered by the Unique filter. The input path must + * that should be considered by the Unique filter. The input path must * already be sorted accordingly. */ Unique * @@ -4124,7 +4124,7 @@ make_unique(Plan *lefttree, List *distinctList) /* * Charge one cpu_operator_cost per comparison per input tuple. We assume - * all columns get compared at most of the tuples. (XXX probably this is + * all columns get compared at most of the tuples. (XXX probably this is * an overestimate.) */ plan->total_cost += cpu_operator_cost * plan->plan_rows * numCols; @@ -4380,7 +4380,7 @@ make_result(PlannerInfo *root, * Build a ModifyTable plan node * * Currently, we don't charge anything extra for the actual table modification - * work, nor for the RETURNING expressions if any. It would only be window + * work, nor for the RETURNING expressions if any. It would only be window * dressing, since these are always top-level nodes and there is no way for * the costs to change any higher-level planning choices. But we might want * to make it look better sometime. |