diff options
Diffstat (limited to 'src/backend/optimizer/path')
| -rw-r--r-- | src/backend/optimizer/path/allpaths.c | 6 | ||||
| -rw-r--r-- | src/backend/optimizer/path/costsize.c | 87 | ||||
| -rw-r--r-- | src/backend/optimizer/path/indxpath.c | 30 | ||||
| -rw-r--r-- | src/backend/optimizer/path/joinpath.c | 16 | ||||
| -rw-r--r-- | src/backend/optimizer/path/joinrels.c | 7 | ||||
| -rw-r--r-- | src/backend/optimizer/path/orindxpath.c | 11 | ||||
| -rw-r--r-- | src/backend/optimizer/path/pathkeys.c | 32 |
7 files changed, 95 insertions, 94 deletions
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 |