diff options
Diffstat (limited to 'src/backend/optimizer')
24 files changed, 274 insertions, 269 deletions
diff --git a/src/backend/optimizer/geqo/geqo_eval.c b/src/backend/optimizer/geqo/geqo_eval.c index 0a2dee08dc8..555ae296092 100644 --- a/src/backend/optimizer/geqo/geqo_eval.c +++ b/src/backend/optimizer/geqo/geqo_eval.c @@ -6,7 +6,7 @@ * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/backend/optimizer/geqo/geqo_eval.c,v 1.77 2005/10/15 02:49:19 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/geqo/geqo_eval.c,v 1.77.2.1 2005/11/22 18:23:10 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -89,10 +89,10 @@ geqo_eval(Gene *tour, int num_gene, GeqoEvalData *evaldata) * truncating the list to its original length. NOTE this assumes that any * added entries are appended at the end! * - * We also must take care not to mess up the outer join_rel_hash, if there is - * one. We can do this by just temporarily setting the link to NULL. (If - * we are dealing with enough join rels, which we very likely are, a new - * hash table will get built and used locally.) + * We also must take care not to mess up the outer join_rel_hash, if there + * is one. We can do this by just temporarily setting the link to NULL. + * (If we are dealing with enough join rels, which we very likely are, a + * new hash table will get built and used locally.) */ savelength = list_length(evaldata->root->join_rel_list); savehash = evaldata->root->join_rel_hash; @@ -182,9 +182,9 @@ gimme_tree(Gene *tour, int num_gene, GeqoEvalData *evaldata) * tour other than the one given. To the extent that the heuristics are * helpful, however, this will be a better plan than the raw tour. * - * Also, when a join attempt fails (because of IN-clause constraints), we may - * be able to recover and produce a workable plan, where the old code just - * had to give up. This case acts the same as a false result from + * Also, when a join attempt fails (because of IN-clause constraints), we + * may be able to recover and produce a workable plan, where the old code + * just had to give up. This case acts the same as a false result from * desirable_join(). */ for (rel_count = 0; rel_count < num_gene; rel_count++) diff --git a/src/backend/optimizer/geqo/geqo_pool.c b/src/backend/optimizer/geqo/geqo_pool.c index 83927facae5..f71cc9fe6b2 100644 --- a/src/backend/optimizer/geqo/geqo_pool.c +++ b/src/backend/optimizer/geqo/geqo_pool.c @@ -6,7 +6,7 @@ * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/backend/optimizer/geqo/geqo_pool.c,v 1.27 2005/10/15 02:49:19 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/geqo/geqo_pool.c,v 1.27.2.1 2005/11/22 18:23:10 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -99,9 +99,9 @@ random_init_pool(Pool *pool, GeqoEvalData *evaldata) * We immediately discard any invalid individuals (those that geqo_eval * returns DBL_MAX for), thereby not wasting pool space on them. * - * If we fail to make any valid individuals after 10000 tries, give up; this - * probably means something is broken, and we shouldn't just let ourselves - * get stuck in an infinite loop. + * If we fail to make any valid individuals after 10000 tries, give up; + * this probably means something is broken, and we shouldn't just let + * ourselves get stuck in an infinite loop. */ i = 0; while (i < pool->size) diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c index d8a42b82548..55e928936cc 100644 --- a/src/backend/optimizer/path/allpaths.c +++ b/src/backend/optimizer/path/allpaths.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/path/allpaths.c,v 1.137 2005/10/15 02:49:19 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/path/allpaths.c,v 1.137.2.1 2005/11/22 18:23:10 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -440,8 +440,8 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel, * Restrictions on individual clauses are checked by * qual_is_pushdown_safe(). * - * Non-pushed-down clauses will get evaluated as qpquals of the SubqueryScan - * node. + * Non-pushed-down clauses will get evaluated as qpquals of the + * SubqueryScan node. * * XXX Are there any cases where we want to make a policy decision not to * push down a pushable qual, because it'd result in a worse plan? diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c index 8a1df9e0a2d..6fe4c77ad0d 100644 --- a/src/backend/optimizer/path/costsize.c +++ b/src/backend/optimizer/path/costsize.c @@ -49,7 +49,7 @@ * Portions Copyright (c) 1994, Regents of the University of California * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/path/costsize.c,v 1.149 2005/10/15 02:49:19 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/path/costsize.c,v 1.149.2.1 2005/11/22 18:23:10 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -155,8 +155,8 @@ cost_seqscan(Path *path, PlannerInfo *root, /* * disk costs * - * The cost of reading a page sequentially is 1.0, by definition. Note that - * the Unix kernel will typically do some amount of read-ahead + * The cost of reading a page sequentially is 1.0, by definition. Note + * that the Unix kernel will typically do some amount of read-ahead * optimization, so that this cost is less than the true cost of reading a * page from disk. We ignore that issue here, but must take it into * account when estimating the cost of non-sequential accesses! @@ -480,8 +480,8 @@ cost_bitmap_heap_scan(Path *path, PlannerInfo *root, RelOptInfo *baserel, /* * Estimate CPU costs per tuple. * - * Often the indexquals don't need to be rechecked at each tuple ... but not - * always, especially not if there are enough tuples involved that the + * Often the indexquals don't need to be rechecked at each tuple ... but + * not always, especially not if there are enough tuples involved that the * bitmaps become lossy. For the moment, just assume they will be * rechecked always. */ @@ -869,13 +869,14 @@ cost_agg(Path *path, PlannerInfo *root, * We will produce a single output tuple if not grouping, and a tuple per * group otherwise. We charge cpu_tuple_cost for each output tuple. * - * Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly the same - * total CPU cost, but AGG_SORTED has lower startup cost. If the input - * path is already sorted appropriately, AGG_SORTED should be preferred - * (since it has no risk of memory overflow). This will happen as long as - * the computed total costs are indeed exactly equal --- but if there's - * roundoff error we might do the wrong thing. So be sure that the - * computations below form the same intermediate values in the same order. + * Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly the + * same total CPU cost, but AGG_SORTED has lower startup cost. If the + * input path is already sorted appropriately, AGG_SORTED should be + * preferred (since it has no risk of memory overflow). This will happen + * as long as the computed total costs are indeed exactly equal --- but if + * there's roundoff error we might do the wrong thing. So be sure that + * the computations below form the same intermediate values in the same + * order. */ if (aggstrategy == AGG_PLAIN) { @@ -1074,8 +1075,8 @@ cost_mergejoin(MergePath *path, PlannerInfo *root) * restriction clauses) separately. We use approx_selectivity here for * speed --- in most cases, any errors won't affect the result much. * - * Note: it's probably bogus to use the normal selectivity calculation here - * when either the outer or inner path is a UniquePath. + * Note: it's probably bogus to use the normal selectivity calculation + * here when either the outer or inner path is a UniquePath. */ merge_selec = approx_selectivity(root, mergeclauses, path->jpath.jointype); @@ -1095,22 +1096,22 @@ cost_mergejoin(MergePath *path, PlannerInfo *root) * but on the other hand we ignore the bookkeeping costs of mark/restore. * Not clear if it's worth developing a more refined model. * - * The number of re-fetches can be estimated approximately as size of merge - * join output minus size of inner relation. Assume that the distinct key - * values are 1, 2, ..., and denote the number of values of each key in - * the outer relation as m1, m2, ...; in the inner relation, n1, n2, ... - * Then we have + * The number of re-fetches can be estimated approximately as size of + * merge join output minus size of inner relation. Assume that the + * distinct key values are 1, 2, ..., and denote the number of values of + * each key in the outer relation as m1, m2, ...; in the inner relation, + * n1, n2, ... Then we have * * size of join = m1 * n1 + m2 * n2 + ... * - * number of rescanned tuples = (m1 - 1) * n1 + (m2 - 1) * n2 + ... = m1 * n1 - * + m2 * n2 + ... - (n1 + n2 + ...) = size of join - size of inner + * number of rescanned tuples = (m1 - 1) * n1 + (m2 - 1) * n2 + ... = m1 * + * n1 + m2 * n2 + ... - (n1 + n2 + ...) = size of join - size of inner * relation * - * This equation works correctly for outer tuples having no inner match (nk = - * 0), but not for inner tuples having no outer match (mk = 0); we are - * effectively subtracting those from the number of rescanned tuples, when - * we should not. Can we do better without expensive selectivity + * This equation works correctly for outer tuples having no inner match + * (nk = 0), but not for inner tuples having no outer match (mk = 0); we + * are effectively subtracting those from the number of rescanned tuples, + * when we should not. Can we do better without expensive selectivity * computations? */ if (IsA(outer_path, UniquePath)) @@ -1132,9 +1133,9 @@ cost_mergejoin(MergePath *path, PlannerInfo *root) * inputs that will actually need to be scanned. We use only the first * (most significant) merge clause for this purpose. * - * Since this calculation is somewhat expensive, and will be the same for all - * mergejoin paths associated with the merge clause, we cache the results - * in the RestrictInfo node. + * Since this calculation is somewhat expensive, and will be the same for + * all mergejoin paths associated with the merge clause, we cache the + * results in the RestrictInfo node. */ if (mergeclauses && path->jpath.jointype != JOIN_FULL) { @@ -1300,8 +1301,8 @@ cost_hashjoin(HashPath *path, PlannerInfo *root) * restriction clauses) separately. We use approx_selectivity here for * speed --- in most cases, any errors won't affect the result much. * - * Note: it's probably bogus to use the normal selectivity calculation here - * when either the outer or inner path is a UniquePath. + * Note: it's probably bogus to use the normal selectivity calculation + * here when either the outer or inner path is a UniquePath. */ hash_selec = approx_selectivity(root, hashclauses, path->jpath.jointype); @@ -1341,8 +1342,8 @@ cost_hashjoin(HashPath *path, PlannerInfo *root) * bucketsize estimated for any individual hashclause; this is undoubtedly * conservative. * - * BUT: if inner relation has been unique-ified, we can assume it's good for - * hashing. This is important both because it's the right answer, and + * BUT: if inner relation has been unique-ified, we can assume it's good + * for hashing. This is important both because it's the right answer, and * because we avoid contaminating the cache with a value that's wrong for * non-unique-ified paths. */ @@ -1538,8 +1539,8 @@ cost_qual_eval_walker(Node *node, QualCost *total) * and so are boolean operators (AND, OR, NOT). Simplistic, but a lot * better than no model at all. * - * Should we try to account for the possibility of short-circuit evaluation - * of AND/OR? + * Should we try to account for the possibility of short-circuit + * evaluation of AND/OR? */ if (IsA(node, FuncExpr) || IsA(node, OpExpr) || @@ -1564,8 +1565,8 @@ cost_qual_eval_walker(Node *node, QualCost *total) * (Sub-selects that can be executed as InitPlans have already been * removed from the expression.) * - * An exception occurs when we have decided we can implement the subplan - * by hashing. + * An exception occurs when we have decided we can implement the + * subplan by hashing. * */ SubPlan *subplan = (SubPlan *) node; @@ -1760,12 +1761,12 @@ set_joinrel_size_estimates(PlannerInfo *root, RelOptInfo *rel, /* * Basically, we multiply size of Cartesian product by selectivity. * - * If we are doing an outer join, take that into account: the output must be - * at least as large as the non-nullable input. (Is there any chance of - * being even smarter?) + * If we are doing an outer join, take that into account: the output must + * be at least as large as the non-nullable input. (Is there any chance + * of being even smarter?) * - * For JOIN_IN and variants, the Cartesian product is figured with respect to - * a unique-ified input, and then we can clamp to the size of the other + * For JOIN_IN and variants, the Cartesian product is figured with respect + * to a unique-ified input, and then we can clamp to the size of the other * input. */ switch (jointype) @@ -1893,8 +1894,8 @@ set_function_size_estimates(PlannerInfo *root, RelOptInfo *rel) /* * Estimate number of rows the function itself will return. * - * XXX no idea how to do this yet; but we can at least check whether function - * returns set or not... + * XXX no idea how to do this yet; but we can at least check whether + * function returns set or not... */ if (expression_returns_set(rte->funcexpr)) rel->tuples = 1000; diff --git a/src/backend/optimizer/path/indxpath.c b/src/backend/optimizer/path/indxpath.c index 466c369cde5..2dbbd0bfbef 100644 --- a/src/backend/optimizer/path/indxpath.c +++ b/src/backend/optimizer/path/indxpath.c @@ -9,7 +9,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.191.2.1 2005/11/14 23:54:35 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.191.2.2 2005/11/22 18:23:10 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -262,8 +262,8 @@ find_usable_indexes(PlannerInfo *root, RelOptInfo *rel, * to imply the predicate. If so, we could use the index in the * current context. * - * We set useful_predicate to true iff the predicate was proven using the - * current set of clauses. This is needed to prevent matching a + * We set useful_predicate to true iff the predicate was proven using + * the current set of clauses. This is needed to prevent matching a * predOK index to an arm of an OR, which would be a legal but * pointlessly inefficient plan. (A better plan will be generated by * just scanning the predOK index alone, no OR.) @@ -524,19 +524,19 @@ choose_bitmap_and(PlannerInfo *root, RelOptInfo *rel, List *paths) * always take the first, and sequentially add on paths that result in a * lower estimated cost. * - * We also make some effort to detect directly redundant input paths, as can - * happen if there are multiple possibly usable indexes. For this we look - * only at plain IndexPath inputs, not at sub-OR clauses. And we consider - * an index redundant if all its index conditions were already used by - * earlier indexes. (We could use predicate_implied_by to have a more - * intelligent, but much more expensive, check --- but in most cases + * We also make some effort to detect directly redundant input paths, as + * can happen if there are multiple possibly usable indexes. For this we + * look only at plain IndexPath inputs, not at sub-OR clauses. And we + * consider an index redundant if all its index conditions were already + * used by earlier indexes. (We could use predicate_implied_by to have a + * more intelligent, but much more expensive, check --- but in most cases * simple pointer equality should suffice, since after all the index * conditions are all coming from the same RestrictInfo lists.) * - * XXX is there any risk of throwing away a useful partial index here because - * we don't explicitly look at indpred? At least in simple cases, the - * partial index will sort before competing non-partial indexes and so it - * makes the right choice, but perhaps we need to work harder. + * XXX is there any risk of throwing away a useful partial index here + * because we don't explicitly look at indpred? At least in simple cases, + * the partial index will sort before competing non-partial indexes and so + * it makes the right choice, but perhaps we need to work harder. * * Note: outputting the selected sub-paths in selectivity order is a good * thing even if we weren't using that as part of the selection method, @@ -920,8 +920,8 @@ check_partial_indexes(PlannerInfo *root, RelOptInfo *rel) * index. For now, the test only uses restriction clauses (those in * baserestrictinfo). --Nels, Dec '92 * - * XXX as of 7.1, equivalence class info *is* available. Consider improving - * this code as foreseen by Nels. + * XXX as of 7.1, equivalence class info *is* available. Consider + * improving this code as foreseen by Nels. */ foreach(ilist, rel->indexlist) diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c index 3d6b333e31e..215d03a9719 100644 --- a/src/backend/optimizer/path/joinpath.c +++ b/src/backend/optimizer/path/joinpath.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.97 2005/10/25 20:30:30 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.97.2.1 2005/11/22 18:23:10 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -176,8 +176,8 @@ sort_inner_and_outer(PlannerInfo *root, * cheapest-startup-cost input paths later, and only if they don't need a * sort. * - * If unique-ification is requested, do it and then handle as a plain inner - * join. + * If unique-ification is requested, do it and then handle as a plain + * inner join. */ outer_path = outerrel->cheapest_total_path; inner_path = innerrel->cheapest_total_path; @@ -512,8 +512,8 @@ match_unsorted_outer(PlannerInfo *root, /* * Generate a mergejoin on the basis of sorting the cheapest inner. - * Since a sort will be needed, only cheapest total cost matters. - * (But create_mergejoin_path will do the right thing if + * Since a sort will be needed, only cheapest total cost matters. (But + * create_mergejoin_path will do the right thing if * inner_cheapest_total is already correctly sorted.) */ add_path(joinrel, (Path *) @@ -804,9 +804,9 @@ select_mergejoin_clauses(RelOptInfo *joinrel, /* * If processing an outer join, only use its own join clauses in the - * merge. For inner joins we can use pushed-down clauses too. - * (Note: we don't set have_nonmergeable_joinclause here because - * pushed-down clauses will become otherquals not joinquals.) + * merge. For inner joins we can use pushed-down clauses too. (Note: + * we don't set have_nonmergeable_joinclause here because pushed-down + * clauses will become otherquals not joinquals.) */ if (isouterjoin && restrictinfo->is_pushed_down) continue; diff --git a/src/backend/optimizer/path/joinrels.c b/src/backend/optimizer/path/joinrels.c index ecb63156860..04ad96f802e 100644 --- a/src/backend/optimizer/path/joinrels.c +++ b/src/backend/optimizer/path/joinrels.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.76 2005/10/15 02:49:20 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.76.2.1 2005/11/22 18:23:10 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -496,8 +496,9 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2, * innerrel is exactly RHS; conversely JOIN_REVERSE_IN handles * RHS/LHS. * - * JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS; conversely - * JOIN_UNIQUE_INNER will work if innerrel is exactly RHS. + * JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS; + * conversely JOIN_UNIQUE_INNER will work if innerrel is exactly + * RHS. * * But none of these will work if we already found another IN that * needs to trigger here. diff --git a/src/backend/optimizer/path/orindxpath.c b/src/backend/optimizer/path/orindxpath.c index 5580b9a2772..8b6f2e4a674 100644 --- a/src/backend/optimizer/path/orindxpath.c +++ b/src/backend/optimizer/path/orindxpath.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/path/orindxpath.c,v 1.75.2.1 2005/11/14 23:54:35 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/path/orindxpath.c,v 1.75.2.2 2005/11/22 18:23:10 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -91,11 +91,10 @@ create_or_index_quals(PlannerInfo *root, RelOptInfo *rel) /* * Find potentially interesting OR joinclauses. Note we must ignore any - * joinclauses that are marked outerjoin_delayed, because they cannot - * be pushed down to the per-relation level due to outer-join rules. - * (XXX in some cases it might be possible to allow this, but it would - * require substantially more bookkeeping about where the clause came - * from.) + * joinclauses that are marked outerjoin_delayed, because they cannot be + * pushed down to the per-relation level due to outer-join rules. (XXX in + * some cases it might be possible to allow this, but it would require + * substantially more bookkeeping about where the clause came from.) */ foreach(i, rel->joininfo) { diff --git a/src/backend/optimizer/path/pathkeys.c b/src/backend/optimizer/path/pathkeys.c index a2626929826..04d0914f036 100644 --- a/src/backend/optimizer/path/pathkeys.c +++ b/src/backend/optimizer/path/pathkeys.c @@ -11,7 +11,7 @@ * Portions Copyright (c) 1994, Regents of the University of California * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.73 2005/10/15 02:49:20 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.73.2.1 2005/11/22 18:23:10 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -125,8 +125,8 @@ add_equijoined_keys(PlannerInfo *root, RestrictInfo *restrictinfo) * structure. If we find both of them in the same equivalence set to * start with, we can quit immediately. * - * This is a standard UNION-FIND problem, for which there exist better data - * structures than simple lists. If this code ever proves to be a + * This is a standard UNION-FIND problem, for which there exist better + * data structures than simple lists. If this code ever proves to be a * bottleneck then it could be sped up --- but for now, simple is * beautiful. */ @@ -255,9 +255,9 @@ generate_implied_equalities(PlannerInfo *root) * Match each item in the set with all that appear after it (it's * sufficient to generate A=B, need not process B=A too). * - * A set containing only two items cannot imply any equalities beyond the - * one that created the set, so we can skip this processing in that - * case. + * A set containing only two items cannot imply any equalities beyond + * the one that created the set, so we can skip this processing in + * that case. */ if (nitems >= 3) { @@ -516,12 +516,12 @@ sub_generate_join_implications(PlannerInfo *root, * the join clause, since both were automatically generated in the * cases we care about. * - * XXX currently this may fail to match in cross-type cases because - * the COALESCE will contain typecast operations while the join - * clause may not (if there is a cross-type mergejoin operator - * available for the two column types). Is it OK to strip implicit - * coercions from the COALESCE arguments? What of the sortops in - * such cases? + * XXX currently this may fail to match in cross-type cases + * because the COALESCE will contain typecast operations while the + * join clause may not (if there is a cross-type mergejoin + * operator available for the two column types). Is it OK to strip + * implicit coercions from the COALESCE arguments? What of the + * sortops in such cases? */ if (equal(leftop, cfirst) && equal(rightop, csecond) && @@ -1151,8 +1151,8 @@ build_join_pathkeys(PlannerInfo *root, * here! The inner-rel vars we used to need to add are *already* part of * the outer pathkey! * - * We do, however, need to truncate the pathkeys list, since it may contain - * pathkeys that were useful for forming this joinrel but are + * We do, however, need to truncate the pathkeys list, since it may + * contain pathkeys that were useful for forming this joinrel but are * uninteresting to higher levels. */ return truncate_useless_pathkeys(root, joinrel, outer_pathkeys); @@ -1299,8 +1299,8 @@ find_mergeclauses_for_pathkeys(PlannerInfo *root, * any redundant mergeclauses from the input list. However, in * outer-join scenarios there might be multiple matches. An example is * - * select * from a full join b on a.v1 = b.v1 and a.v2 = b.v2 and a.v1 = - * b.v2; + * select * from a full join b on a.v1 = b.v1 and a.v2 = b.v2 and a.v1 + * = b.v2; * * Given the pathkeys ((a.v1), (a.v2)) it is okay to return all three * clauses (in the order a.v1=b.v1, a.v1=b.v2, a.v2=b.v2) and indeed diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c index fc093fdf180..0a474fa8ce4 100644 --- a/src/backend/optimizer/plan/createplan.c +++ b/src/backend/optimizer/plan/createplan.c @@ -10,7 +10,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/plan/createplan.c,v 1.202 2005/10/19 17:31:20 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/plan/createplan.c,v 1.202.2.1 2005/11/22 18:23:10 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -325,7 +325,7 @@ use_physical_tlist(RelOptInfo *rel) /* * Can't do it if any system columns or whole-row Vars are requested, - * either. (This could possibly be fixed but would take some fragile + * either. (This could possibly be fixed but would take some fragile * assumptions in setrefs.c, I think.) */ for (i = rel->min_attr; i <= 0; i++) @@ -1251,8 +1251,8 @@ create_nestloop_plan(PlannerInfo *root, * caught this case because the join clauses would never have been put * in the same joininfo list. * - * We can skip this if the index path is an ordinary indexpath and not a - * special innerjoin path. + * We can skip this if the index path is an ordinary indexpath and not + * a special innerjoin path. */ IndexPath *innerpath = (IndexPath *) best_path->innerjoinpath; @@ -1270,13 +1270,13 @@ create_nestloop_plan(PlannerInfo *root, /* * Same deal for bitmapped index scans. * - * Note: both here and above, we ignore any implicit index restrictions - * associated with the use of partial indexes. This is OK because - * we're only trying to prove we can dispense with some join quals; - * failing to prove that doesn't result in an incorrect plan. It is - * the right way to proceed because adding more quals to the stuff we - * got from the original query would just make it harder to detect - * duplication. + * Note: both here and above, we ignore any implicit index + * restrictions associated with the use of partial indexes. This is + * OK because we're only trying to prove we can dispense with some + * join quals; failing to prove that doesn't result in an incorrect + * plan. It is the right way to proceed because adding more quals to + * the stuff we got from the original query would just make it harder + * to detect duplication. */ BitmapHeapPath *innerpath = (BitmapHeapPath *) best_path->innerjoinpath; @@ -1547,8 +1547,9 @@ fix_indexqual_references(List *indexquals, IndexPath *index_path, /* * Make a copy that will become the fixed clause. * - * We used to try to do a shallow copy here, but that fails if there is a - * subplan in the arguments of the opclause. So just do a full copy. + * We used to try to do a shallow copy here, but that fails if there + * is a subplan in the arguments of the opclause. So just do a full + * copy. */ newclause = (OpExpr *) copyObject((Node *) clause); @@ -2232,8 +2233,8 @@ make_sort_from_pathkeys(PlannerInfo *root, Plan *lefttree, List *pathkeys) * available Var in the tlist. If there isn't any, use the first one * that is an expression in the input's vars. * - * XXX if we have a choice, is there any way of figuring out which might - * be cheapest to execute? (For example, int4lt is likely much + * XXX if we have a choice, is there any way of figuring out which + * might be cheapest to execute? (For example, int4lt is likely much * cheaper to execute than numericlt, but both might appear in the * same pathkey sublist...) Not clear that we ever will have a choice * in practice, so it may not matter. @@ -2553,12 +2554,13 @@ make_group(PlannerInfo *root, * We also need to account for the cost of evaluation of the qual (ie, the * HAVING clause) and the tlist. * - * XXX this double-counts the cost of evaluation of any expressions used for - * grouping, since in reality those will have been evaluated at a lower - * plan level and will only be copied by the Group node. Worth fixing? + * XXX this double-counts the cost of evaluation of any expressions used + * for grouping, since in reality those will have been evaluated at a + * lower plan level and will only be copied by the Group node. Worth + * fixing? * - * See notes in grouping_planner about why this routine and make_agg are the - * only ones in this file that worry about tlist eval cost. + * See notes in grouping_planner about why this routine and make_agg are + * the only ones in this file that worry about tlist eval cost. */ if (qual) { @@ -2715,8 +2717,8 @@ make_limit(Plan *lefttree, Node *limitOffset, Node *limitCount, * building a subquery then it's important to report correct info to the * outer planner. * - * When the offset or count couldn't be estimated, use 10% of the estimated - * number of rows emitted from the subplan. + * When the offset or count couldn't be estimated, use 10% of the + * estimated number of rows emitted from the subplan. */ if (offset_est != 0) { diff --git a/src/backend/optimizer/plan/initsplan.c b/src/backend/optimizer/plan/initsplan.c index 0901c66518c..66f5dc9d3d6 100644 --- a/src/backend/optimizer/plan/initsplan.c +++ b/src/backend/optimizer/plan/initsplan.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/plan/initsplan.c,v 1.110.2.1 2005/11/14 23:54:35 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/plan/initsplan.c,v 1.110.2.2 2005/11/22 18:23:11 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -466,8 +466,8 @@ distribute_qual_to_rels(PlannerInfo *root, Node *clause, * we'd produce no output rows, rather than the intended single * null-extended row, for any nonnullable-side rows failing the qual. * - * Note: an outer-join qual that mentions only nullable-side rels can be - * pushed down into the nullable side without changing the join + * Note: an outer-join qual that mentions only nullable-side rels can + * be pushed down into the nullable side without changing the join * result, so we treat it the same as an ordinary inner-join qual, * except for not setting maybe_equijoin (see below). */ @@ -860,8 +860,8 @@ process_implied_equality(PlannerInfo *root, /* * Push the new clause into all the appropriate restrictinfo lists. * - * Note: we mark the qual "pushed down" to ensure that it can never be taken - * for an original JOIN/ON clause. + * Note: we mark the qual "pushed down" to ensure that it can never be + * taken for an original JOIN/ON clause. */ distribute_qual_to_rels(root, (Node *) clause, true, true, false, NULL, relids); diff --git a/src/backend/optimizer/plan/planagg.c b/src/backend/optimizer/plan/planagg.c index 7c2f0211f10..a63f85ba511 100644 --- a/src/backend/optimizer/plan/planagg.c +++ b/src/backend/optimizer/plan/planagg.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/plan/planagg.c,v 1.10 2005/10/15 02:49:20 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/plan/planagg.c,v 1.10.2.1 2005/11/22 18:23:11 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -93,9 +93,9 @@ optimize_minmax_aggregates(PlannerInfo *root, List *tlist, Path *best_path) /* * Reject unoptimizable cases. * - * We don't handle GROUP BY, because our current implementations of grouping - * require looking at all the rows anyway, and so there's not much point - * in optimizing MIN/MAX. + * We don't handle GROUP BY, because our current implementations of + * grouping require looking at all the rows anyway, and so there's not + * much point in optimizing MIN/MAX. */ if (parse->groupClause) return NULL; @@ -160,9 +160,9 @@ optimize_minmax_aggregates(PlannerInfo *root, List *tlist, Path *best_path) /* * Make the cost comparison. * - * Note that we don't include evaluation cost of the tlist here; this is OK - * since it isn't included in best_path's cost either, and should be the - * same in either case. + * Note that we don't include evaluation cost of the tlist here; this is + * OK since it isn't included in best_path's cost either, and should be + * the same in either case. */ cost_agg(&agg_p, root, AGG_PLAIN, list_length(aggs_list), 0, 0, @@ -493,12 +493,12 @@ make_agg_subplan(PlannerInfo *root, MinMaxAggInfo *info, List *constant_quals) * node above it. We might need a gating Result, too, to handle any * non-variable qual clauses. * - * Also we must add a "WHERE foo IS NOT NULL" restriction to the indexscan, - * to be sure we don't return a NULL, which'd be contrary to the standard - * behavior of MIN/MAX. XXX ideally this should be done earlier, so that - * the selectivity of the restriction could be included in our cost - * estimates. But that looks painful, and in most cases the fraction of - * NULLs isn't high enough to change the decision. + * Also we must add a "WHERE foo IS NOT NULL" restriction to the + * indexscan, to be sure we don't return a NULL, which'd be contrary to + * the standard behavior of MIN/MAX. XXX ideally this should be done + * earlier, so that the selectivity of the restriction could be included + * in our cost estimates. But that looks painful, and in most cases the + * fraction of NULLs isn't high enough to change the decision. */ plan = create_plan(&subroot, (Path *) info->path); diff --git a/src/backend/optimizer/plan/planmain.c b/src/backend/optimizer/plan/planmain.c index ecbf44400c9..fc46c7aaf44 100644 --- a/src/backend/optimizer/plan/planmain.c +++ b/src/backend/optimizer/plan/planmain.c @@ -14,7 +14,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/plan/planmain.c,v 1.89 2005/10/15 02:49:20 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/plan/planmain.c,v 1.89.2.1 2005/11/22 18:23:11 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -146,11 +146,11 @@ query_planner(PlannerInfo *root, List *tlist, double tuple_fraction, * added to appropriate lists belonging to the mentioned relations. We * also build lists of equijoined keys for pathkey construction. * - * Note: all subplan nodes will have "flat" (var-only) tlists. This implies - * that all expression evaluations are done at the root of the plan tree. - * Once upon a time there was code to try to push expensive function calls - * down to lower plan nodes, but that's dead code and has been for a long - * time... + * Note: all subplan nodes will have "flat" (var-only) tlists. This + * implies that all expression evaluations are done at the root of the + * plan tree. Once upon a time there was code to try to push expensive + * function calls down to lower plan nodes, but that's dead code and has + * been for a long time... */ build_base_rel_tlists(root, tlist); @@ -273,9 +273,9 @@ query_planner(PlannerInfo *root, List *tlist, double tuple_fraction, * "cheapest presorted" path will be the cheapest overall for the tuple * fraction.) * - * The cheapest-total path is also the one to use if grouping_planner decides - * to use hashed aggregation, so we return it separately even if this - * routine thinks the presorted path is the winner. + * The cheapest-total path is also the one to use if grouping_planner + * decides to use hashed aggregation, so we return it separately even if + * this routine thinks the presorted path is the winner. */ cheapestpath = final_rel->cheapest_total_path; diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c index 762dfb4b641..b1beb2c834e 100644 --- a/src/backend/optimizer/plan/planner.c +++ b/src/backend/optimizer/plan/planner.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.194 2005/10/15 02:49:20 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.194.2.1 2005/11/22 18:23:11 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -99,9 +99,9 @@ planner(Query *parse, bool isCursor, int cursorOptions, * multiple sub-queries. Also, boundParams is explicitly info from outside * the query, and so is likewise better handled as a global variable. * - * Note we do NOT save and restore PlannerPlanId: it exists to assign unique - * IDs to SubPlan nodes, and we want those IDs to be unique for the life - * of a backend. Also, PlannerInitPlan is saved/restored in + * Note we do NOT save and restore PlannerPlanId: it exists to assign + * unique IDs to SubPlan nodes, and we want those IDs to be unique for the + * life of a backend. Also, PlannerInitPlan is saved/restored in * subquery_planner, not here. */ save_PlannerQueryLevel = PlannerQueryLevel; @@ -302,14 +302,14 @@ subquery_planner(Query *parse, double tuple_fraction, * HAVING clause into WHERE, in hopes of eliminating tuples before * aggregation instead of after. * - * If the query has explicit grouping then we can simply move such a clause - * into WHERE; any group that fails the clause will not be in the output - * because none of its tuples will reach the grouping or aggregation - * stage. Otherwise we must have a degenerate (variable-free) HAVING - * clause, which we put in WHERE so that query_planner() can use it in a - * gating Result node, but also keep in HAVING to ensure that we don't - * emit a bogus aggregated row. (This could be done better, but it seems - * not worth optimizing.) + * If the query has explicit grouping then we can simply move such a + * clause into WHERE; any group that fails the clause will not be in the + * output because none of its tuples will reach the grouping or + * aggregation stage. Otherwise we must have a degenerate (variable-free) + * HAVING clause, which we put in WHERE so that query_planner() can use it + * in a gating Result node, but also keep in HAVING to ensure that we + * don't emit a bogus aggregated row. (This could be done better, but it + * seems not worth optimizing.) * * Note that both havingQual and parse->jointree->quals are in * implicitly-ANDed-list form at this point, even though they are declared @@ -426,8 +426,8 @@ preprocess_expression(PlannerInfo *root, Node *expr, int kind) * careful to maintain AND/OR flatness --- that is, do not generate a tree * with AND directly under AND, nor OR directly under OR. * - * Because this is a relatively expensive process, we skip it when the query - * is trivial, such as "SELECT 2+2;" or "INSERT ... VALUES()". The + * Because this is a relatively expensive process, we skip it when the + * query is trivial, such as "SELECT 2+2;" or "INSERT ... VALUES()". The * expression will only be evaluated once anyway, so no point in * pre-simplifying; we can't execute it any faster than the executor can, * and we will waste cycles copying the tree. Notice however that we @@ -577,13 +577,13 @@ inheritance_planner(PlannerInfo *root, List *inheritlist) * XXX my goodness this next bit is ugly. Really need to think about * ways to rein in planner's habit of scribbling on its input. * - * Planning of the subquery might have modified the rangetable, either by - * addition of RTEs due to expansion of inherited source tables, or by - * changes of the Query structures inside subquery RTEs. We have to - * ensure that this gets propagated back to the master copy. However, - * if we aren't done planning yet, we also need to ensure that - * subsequent calls to grouping_planner have virgin sub-Queries to - * work from. So, if we are at the last list entry, just copy the + * Planning of the subquery might have modified the rangetable, either + * by addition of RTEs due to expansion of inherited source tables, or + * by changes of the Query structures inside subquery RTEs. We have + * to ensure that this gets propagated back to the master copy. + * However, if we aren't done planning yet, we also need to ensure + * that subsequent calls to grouping_planner have virgin sub-Queries + * to work from. So, if we are at the last list entry, just copy the * subquery rangetable back to the master copy; if we are not, then * extend the master copy by adding whatever the subquery added. (We * assume these added entries will go untouched by the future @@ -759,8 +759,8 @@ grouping_planner(PlannerInfo *root, double tuple_fraction) * Note: we do not attempt to detect duplicate aggregates here; a * somewhat-overestimated count is okay for our present purposes. * - * Note: think not that we can turn off hasAggs if we find no aggs. It is - * possible for constant-expression simplification to remove all + * Note: think not that we can turn off hasAggs if we find no aggs. It + * is possible for constant-expression simplification to remove all * explicit references to aggs, but we still have to follow the * aggregate semantics (eg, producing only one output row). */ @@ -980,8 +980,8 @@ grouping_planner(PlannerInfo *root, double tuple_fraction) * GROUP BY without aggregation, so insert a group node (plus * the appropriate sort node, if necessary). * - * Add an explicit sort if we couldn't make the path come out the - * way the GROUP node needs it. + * Add an explicit sort if we couldn't make the path come out + * the way the GROUP node needs it. */ if (!pathkeys_contained_in(group_pathkeys, current_pathkeys)) { @@ -1329,14 +1329,15 @@ choose_hashed_grouping(PlannerInfo *root, double tuple_fraction, * output won't be sorted may be a loss; so we need to do an actual cost * comparison. * - * We need to consider cheapest_path + hashagg [+ final sort] versus either - * cheapest_path [+ sort] + group or agg [+ final sort] or presorted_path - * + group or agg [+ final sort] where brackets indicate a step that may - * not be needed. We assume query_planner() will have returned a presorted - * path only if it's a winner compared to cheapest_path for this purpose. + * We need to consider cheapest_path + hashagg [+ final sort] versus + * either cheapest_path [+ sort] + group or agg [+ final sort] or + * presorted_path + group or agg [+ final sort] where brackets indicate a + * step that may not be needed. We assume query_planner() will have + * returned a presorted path only if it's a winner compared to + * cheapest_path for this purpose. * - * These path variables are dummies that just hold cost fields; we don't make - * actual Paths for these steps. + * These path variables are dummies that just hold cost fields; we don't + * make actual Paths for these steps. */ cost_agg(&hashed_p, root, AGG_HASHED, agg_counts->numAggs, numGroupCols, dNumGroups, diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c index e6f97fa0815..f206eefd75d 100644 --- a/src/backend/optimizer/plan/setrefs.c +++ b/src/backend/optimizer/plan/setrefs.c @@ -9,7 +9,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/plan/setrefs.c,v 1.117 2005/11/03 17:45:29 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/plan/setrefs.c,v 1.117.2.1 2005/11/22 18:23:11 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -608,8 +608,8 @@ adjust_plan_varnos(Plan *plan, int rtoffset) /* * Now recurse into child plans. * - * We don't need to (and in fact mustn't) recurse into subqueries, so no need - * to examine initPlan list. + * We don't need to (and in fact mustn't) recurse into subqueries, so no + * need to examine initPlan list. */ adjust_plan_varnos(plan->lefttree, rtoffset); adjust_plan_varnos(plan->righttree, rtoffset); @@ -853,8 +853,8 @@ set_inner_join_references(Plan *inner_plan, * The inner side is a bitmap scan plan. Fix the top node, and * recurse to get the lower nodes. * - * Note: create_bitmap_scan_plan removes clauses from bitmapqualorig if - * they are duplicated in qpqual, so must test these independently. + * Note: create_bitmap_scan_plan removes clauses from bitmapqualorig + * if they are duplicated in qpqual, so must test these independently. */ BitmapHeapScan *innerscan = (BitmapHeapScan *) inner_plan; Index innerrel = innerscan->scan.scanrelid; diff --git a/src/backend/optimizer/plan/subselect.c b/src/backend/optimizer/plan/subselect.c index b0dc9c5bf7f..e621e710f5b 100644 --- a/src/backend/optimizer/plan/subselect.c +++ b/src/backend/optimizer/plan/subselect.c @@ -7,7 +7,7 @@ * Portions Copyright (c) 1994, Regents of the University of California * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/plan/subselect.c,v 1.100 2005/10/15 02:49:20 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/plan/subselect.c,v 1.100.2.1 2005/11/22 18:23:11 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -118,10 +118,10 @@ replace_outer_var(Var *var) * this sort of aliasing will cause no trouble. The correct field should * get stored into the Param slot at execution in each part of the tree. * - * We also need to demand a match on vartypmod. This does not matter for the - * Param itself, since those are not typmod-dependent, but it does matter - * when make_subplan() instantiates a modified copy of the Var for a - * subplan's args list. + * We also need to demand a match on vartypmod. This does not matter for + * the Param itself, since those are not typmod-dependent, but it does + * matter when make_subplan() instantiates a modified copy of the Var for + * a subplan's args list. */ i = 0; foreach(ppl, PlannerParamList) @@ -267,8 +267,8 @@ make_subplan(SubLink *slink, List *lefthand, bool isTopQual) * 50% retrieval. For EXPR and MULTIEXPR subplans, use default behavior * (we're only expecting one row out, anyway). * - * NOTE: if you change these numbers, also change cost_qual_eval_walker() in - * path/costsize.c. + * NOTE: if you change these numbers, also change cost_qual_eval_walker() + * in path/costsize.c. * * XXX If an ALL/ANY subplan is uncorrelated, we may decide to hash or * materialize its result below. In that case it would've been better to @@ -698,10 +698,10 @@ convert_IN_to_join(PlannerInfo *root, SubLink *sublink) /* * Okay, pull up the sub-select into top range table and jointree. * - * We rely here on the assumption that the outer query has no references to - * the inner (necessarily true, other than the Vars that we build below). - * Therefore this is a lot easier than what pull_up_subqueries has to go - * through. + * We rely here on the assumption that the outer query has no references + * to the inner (necessarily true, other than the Vars that we build + * below). Therefore this is a lot easier than what pull_up_subqueries has + * to go through. */ rte = addRangeTableEntryForSubquery(NULL, subselect, @@ -938,9 +938,9 @@ SS_finalize_plan(Plan *plan, List *rtable) * Finally, attach any initPlans to the topmost plan node, and add their * extParams to the topmost node's, too. * - * We also add the total_cost of each initPlan to the startup cost of the top - * node. This is a conservative overestimate, since in fact each initPlan - * might be executed later than plan startup, or even not at all. + * We also add the total_cost of each initPlan to the startup cost of the + * top node. This is a conservative overestimate, since in fact each + * initPlan might be executed later than plan startup, or even not at all. */ plan->initPlan = PlannerInitPlan; PlannerInitPlan = NIL; /* make sure they're not attached twice */ diff --git a/src/backend/optimizer/prep/prepjointree.c b/src/backend/optimizer/prep/prepjointree.c index ece6133c144..cc043d613d1 100644 --- a/src/backend/optimizer/prep/prepjointree.c +++ b/src/backend/optimizer/prep/prepjointree.c @@ -16,7 +16,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/prep/prepjointree.c,v 1.31 2005/10/15 02:49:20 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/prep/prepjointree.c,v 1.31.2.1 2005/11/22 18:23:11 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -198,9 +198,9 @@ pull_up_subqueries(PlannerInfo *root, Node *jtnode, bool below_outer_join) * routine's processing is complete for its jointree and * rangetable. * - * Note: 'false' is correct here even if we are within an outer join - * in the upper query; the lower query starts with a clean slate - * for outer-join semantics. + * Note: 'false' is correct here even if we are within an outer + * join in the upper query; the lower query starts with a clean + * slate for outer-join semantics. */ subquery->jointree = (FromExpr *) pull_up_subqueries(subroot, (Node *) subquery->jointree, @@ -210,9 +210,9 @@ pull_up_subqueries(PlannerInfo *root, Node *jtnode, bool below_outer_join) * Now we must recheck whether the subquery is still simple enough * to pull up. If not, abandon processing it. * - * We don't really need to recheck all the conditions involved, but - * it's easier just to keep this "if" looking the same as the one - * above. + * We don't really need to recheck all the conditions involved, + * but it's easier just to keep this "if" looking the same as the + * one above. */ if (is_simple_subquery(subquery) && (!below_outer_join || has_nullable_targetlist(subquery))) @@ -294,8 +294,8 @@ pull_up_subqueries(PlannerInfo *root, Node *jtnode, bool below_outer_join) * already adjusted the marker values, so just list_concat the * list.) * - * Executor can't handle multiple FOR UPDATE/SHARE/NOWAIT flags, so - * complain if they are valid but different + * Executor can't handle multiple FOR UPDATE/SHARE/NOWAIT flags, + * so complain if they are valid but different */ if (parse->rowMarks && subquery->rowMarks) { diff --git a/src/backend/optimizer/prep/prepqual.c b/src/backend/optimizer/prep/prepqual.c index 9fad52acfe0..6613e763fe3 100644 --- a/src/backend/optimizer/prep/prepqual.c +++ b/src/backend/optimizer/prep/prepqual.c @@ -25,7 +25,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/prep/prepqual.c,v 1.51 2005/10/15 02:49:21 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/prep/prepqual.c,v 1.51.2.1 2005/11/22 18:23:11 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -431,9 +431,9 @@ process_duplicate_ors(List *orlist) /* * Generate new OR list consisting of the remaining sub-clauses. * - * If any clause degenerates to empty, then we have a situation like (A AND - * B) OR (A), which can be reduced to just A --- that is, the additional - * conditions in other arms of the OR are irrelevant. + * If any clause degenerates to empty, then we have a situation like (A + * AND B) OR (A), which can be reduced to just A --- that is, the + * additional conditions in other arms of the OR are irrelevant. * * Note that because we use list_difference, any multiple occurrences of a * winning clause in an AND sub-clause will be removed automatically. diff --git a/src/backend/optimizer/prep/preptlist.c b/src/backend/optimizer/prep/preptlist.c index f23d0554e7c..9049a3be0bb 100644 --- a/src/backend/optimizer/prep/preptlist.c +++ b/src/backend/optimizer/prep/preptlist.c @@ -15,7 +15,7 @@ * Portions Copyright (c) 1994, Regents of the University of California * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/prep/preptlist.c,v 1.78 2005/10/15 02:49:21 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/prep/preptlist.c,v 1.78.2.1 2005/11/22 18:23:11 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -64,8 +64,8 @@ preprocess_targetlist(PlannerInfo *root, List *tlist) /* * for heap_formtuple to work, the targetlist must match the exact order - * of the attributes. We also need to fill in any missing attributes. - * -ay 10/94 + * of the attributes. We also need to fill in any missing attributes. -ay + * 10/94 */ if (command_type == CMD_INSERT || command_type == CMD_UPDATE) tlist = expand_targetlist(tlist, command_type, @@ -185,10 +185,10 @@ expand_targetlist(List *tlist, int command_type, * The rewriter should have already ensured that the TLEs are in correct * order; but we have to insert TLEs for any missing attributes. * - * Scan the tuple description in the relation's relcache entry to make sure - * we have all the user attributes in the right order. We assume that the - * rewriter already acquired at least AccessShareLock on the relation, so - * we need no lock here. + * Scan the tuple description in the relation's relcache entry to make + * sure we have all the user attributes in the right order. We assume + * that the rewriter already acquired at least AccessShareLock on the + * relation, so we need no lock here. */ rel = heap_open(getrelid(result_relation, range_table), NoLock); @@ -220,18 +220,19 @@ expand_targetlist(List *tlist, int command_type, * column isn't dropped, apply any domain constraints that might * exist --- this is to catch domain NOT NULL. * - * For UPDATE, generate a Var reference to the existing value of the - * attribute, so that it gets copied to the new tuple. But + * For UPDATE, generate a Var reference to the existing value of + * the attribute, so that it gets copied to the new tuple. But * generate a NULL for dropped columns (we want to drop any old * values). * - * When generating a NULL constant for a dropped column, we label it - * INT4 (any other guaranteed-to-exist datatype would do as well). - * We can't label it with the dropped column's datatype since that - * might not exist anymore. It does not really matter what we - * claim the type is, since NULL is NULL --- its representation is - * datatype-independent. This could perhaps confuse code - * comparing the finished plan to the target relation, however. + * When generating a NULL constant for a dropped column, we label + * it INT4 (any other guaranteed-to-exist datatype would do as + * well). We can't label it with the dropped column's datatype + * since that might not exist anymore. It does not really matter + * what we claim the type is, since NULL is NULL --- its + * representation is datatype-independent. This could perhaps + * confuse code comparing the finished plan to the target + * relation, however. */ Oid atttype = att_tup->atttypid; int32 atttypmod = att_tup->atttypmod; diff --git a/src/backend/optimizer/prep/prepunion.c b/src/backend/optimizer/prep/prepunion.c index dc7d94e1c6c..11ce490ddc3 100644 --- a/src/backend/optimizer/prep/prepunion.c +++ b/src/backend/optimizer/prep/prepunion.c @@ -14,7 +14,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/prep/prepunion.c,v 1.127 2005/10/15 02:49:21 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/prep/prepunion.c,v 1.127.2.1 2005/11/22 18:23:11 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -439,8 +439,8 @@ recurse_union_children(Node *setOp, PlannerInfo *root, /* * Not same, so plan this child separately. * - * Note we disallow any resjunk columns in child results. This is necessary - * since the Append node that implements the union won't do any + * Note we disallow any resjunk columns in child results. This is + * necessary since the Append node that implements the union won't do any * projection, and upper levels will get confused if some of our output * tuples have junk and some don't. This case only arises when we have an * EXCEPT or INTERSECT as child, else there won't be resjunk anyway. @@ -495,9 +495,9 @@ generate_setop_tlist(List *colTypes, int flag, * data types and column names. Insert datatype coercions where * necessary. * - * HACK: constants in the input's targetlist are copied up as-is rather - * than being referenced as subquery outputs. This is mainly to - * ensure that when we try to coerce them to the output column's + * HACK: constants in the input's targetlist are copied up as-is + * rather than being referenced as subquery outputs. This is mainly + * to ensure that when we try to coerce them to the output column's * datatype, the right things happen for UNKNOWN constants. But do * this only at the first level of subquery-scan plans; we don't want * phony constants appearing in the output tlists of upper-level diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c index 5e2718dc635..fc8d530b1e8 100644 --- a/src/backend/optimizer/util/clauses.c +++ b/src/backend/optimizer/util/clauses.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/util/clauses.c,v 1.201 2005/10/15 02:49:21 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/util/clauses.c,v 1.201.2.1 2005/11/22 18:23:12 momjian Exp $ * * HISTORY * AUTHOR DATE MAJOR EVENT @@ -1803,8 +1803,8 @@ eval_const_expressions_mutator(Node *node, * simplifying functions.) Also, we can optimize field selection from * a RowExpr construct. * - * We must however check that the declared type of the field is still the - * same as when the FieldSelect was created --- this can change if + * We must however check that the declared type of the field is still + * the same as when the FieldSelect was created --- this can change if * someone did ALTER COLUMN TYPE on the rowtype. */ FieldSelect *fselect = (FieldSelect *) node; @@ -2638,10 +2638,10 @@ evaluate_expr(Expr *expr, Oid result_type) /* * And evaluate it. * - * It is OK to use a default econtext because none of the ExecEvalExpr() code - * used in this situation will use econtext. That might seem fortuitous, - * but it's not so unreasonable --- a constant expression does not depend - * on context, by definition, n'est ce pas? + * It is OK to use a default econtext because none of the ExecEvalExpr() + * code used in this situation will use econtext. That might seem + * fortuitous, but it's not so unreasonable --- a constant expression does + * not depend on context, by definition, n'est ce pas? */ const_val = ExecEvalExprSwitchContext(exprstate, GetPerTupleExprContext(estate), @@ -2774,9 +2774,9 @@ expression_tree_walker(Node *node, * The walker has already visited the current node, and so we need only * recurse into any sub-nodes it has. * - * We assume that the walker is not interested in List nodes per se, so when - * we expect a List we just recurse directly to self without bothering to - * call the walker. + * We assume that the walker is not interested in List nodes per se, so + * when we expect a List we just recurse directly to self without + * bothering to call the walker. */ if (node == NULL) return false; diff --git a/src/backend/optimizer/util/plancat.c b/src/backend/optimizer/util/plancat.c index 16868939405..f3d4e75ece6 100644 --- a/src/backend/optimizer/util/plancat.c +++ b/src/backend/optimizer/util/plancat.c @@ -9,7 +9,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/util/plancat.c,v 1.114 2005/10/15 02:49:21 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/util/plancat.c,v 1.114.2.1 2005/11/22 18:23:12 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -132,10 +132,10 @@ get_relation_info(Oid relationObjectId, RelOptInfo *rel) /* * Extract info from the relation descriptor for the index. * - * Note that we take no lock on the index; we assume our lock on the - * parent table will protect the index's schema information. When - * and if the executor actually uses the index, it will take a - * lock as needed to protect the access to the index contents. + * Note that we take no lock on the index; we assume our lock on + * the parent table will protect the index's schema information. + * When and if the executor actually uses the index, it will take + * a lock as needed to protect the access to the index contents. */ indexRelation = index_open(indexoid); index = indexRelation->rd_index; @@ -265,11 +265,11 @@ estimate_rel_size(Relation rel, int32 *attr_widths, * infrastructure for redoing cached plans at all, so we have to * kluge things here instead. * - * We approximate "never vacuumed" by "has relpages = 0", which means - * this will also fire on genuinely empty relations. Not great, - * but fortunately that's a seldom-seen case in the real world, - * and it shouldn't degrade the quality of the plan too much - * anyway to err in this direction. + * We approximate "never vacuumed" by "has relpages = 0", which + * means this will also fire on genuinely empty relations. Not + * great, but fortunately that's a seldom-seen case in the real + * world, and it shouldn't degrade the quality of the plan too + * much anyway to err in this direction. */ if (curpages < 10 && rel->rd_rel->relpages == 0) curpages = 10; diff --git a/src/backend/optimizer/util/relnode.c b/src/backend/optimizer/util/relnode.c index 3ca43759e96..20b656e0b30 100644 --- a/src/backend/optimizer/util/relnode.c +++ b/src/backend/optimizer/util/relnode.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/util/relnode.c,v 1.72 2005/10/15 02:49:21 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/util/relnode.c,v 1.72.2.1 2005/11/22 18:23:12 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -263,9 +263,9 @@ find_join_rel(PlannerInfo *root, Relids relids) /* * Use either hashtable lookup or linear search, as appropriate. * - * Note: the seemingly redundant hashkey variable is used to avoid taking the - * address of relids; unless the compiler is exceedingly smart, doing so - * would force relids out of a register and thus probably slow down the + * Note: the seemingly redundant hashkey variable is used to avoid taking + * the address of relids; unless the compiler is exceedingly smart, doing + * so would force relids out of a register and thus probably slow down the * list-search case. */ if (root->join_rel_hash) @@ -533,8 +533,8 @@ build_joinrel_restrictlist(PlannerInfo *root, /* * Eliminate duplicate and redundant clauses. * - * We must eliminate duplicates, since we will see many of the same clauses - * arriving from both input relations. Also, if a clause is a + * We must eliminate duplicates, since we will see many of the same + * clauses arriving from both input relations. Also, if a clause is a * mergejoinable clause, it's possible that it is redundant with previous * clauses (see optimizer/README for discussion). We detect that case and * omit the redundant clause from the result list. diff --git a/src/backend/optimizer/util/restrictinfo.c b/src/backend/optimizer/util/restrictinfo.c index 475e51bca6f..076bffd6f12 100644 --- a/src/backend/optimizer/util/restrictinfo.c +++ b/src/backend/optimizer/util/restrictinfo.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/util/restrictinfo.c,v 1.41.2.2 2005/11/16 17:08:12 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/util/restrictinfo.c,v 1.41.2.3 2005/11/22 18:23:12 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -43,7 +43,7 @@ static RestrictInfo *join_clause_is_redundant(PlannerInfo *root, * Build a RestrictInfo node containing the given subexpression. * * The is_pushed_down and outerjoin_delayed flags must be supplied by the - * caller. required_relids can be NULL, in which case it defaults to the + * caller. required_relids can be NULL, in which case it defaults to the * actual clause contents (i.e., clause_relids). * * We initialize fields that depend only on the given subexpression, leaving |