database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list

Browse Source 
provided by Andrew.
This commit is contained in:
Bruce Momjian
2009-06-11 14:49:15 +00:00
parent 4e86efb4e5
commit d747140279
654 changed files with 11900 additions and 11387 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
src/backend/optimizer/path/allpaths.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/allpaths.c,v 1.182 2009/04/19 19:46:33 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/allpaths.c,v 1.183 2009/06/11 14:48:58 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -58,9 +58,9 @@ static void set_function_pathlist(PlannerInfo *root, RelOptInfo *rel,
static void set_values_pathlist(PlannerInfo *root, RelOptInfo *rel,
RangeTblEntry *rte);
static void set_cte_pathlist(PlannerInfo *root, RelOptInfo *rel,
RangeTblEntry *rte);
RangeTblEntry *rte);
static void set_worktable_pathlist(PlannerInfo *root, RelOptInfo *rel,
RangeTblEntry *rte);
RangeTblEntry *rte);
static RelOptInfo *make_rel_from_joinlist(PlannerInfo *root, List *joinlist);
static bool subquery_is_pushdown_safe(Query *subquery, Query *topquery,
bool *differentTypes);
@ -292,13 +292,13 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
/*
* Initialize to compute size estimates for whole append relation.
*
* We handle width estimates by weighting the widths of different
* child rels proportionally to their number of rows. This is sensible
* because the use of width estimates is mainly to compute the total
* relation "footprint" if we have to sort or hash it. To do this,
* we sum the total equivalent size (in "double" arithmetic) and then
* divide by the total rowcount estimate. This is done separately for
* the total rel width and each attribute.
* We handle width estimates by weighting the widths of different child
* rels proportionally to their number of rows. This is sensible because
* the use of width estimates is mainly to compute the total relation
* "footprint" if we have to sort or hash it. To do this, we sum the
* total equivalent size (in "double" arithmetic) and then divide by the
* total rowcount estimate. This is done separately for the total rel
* width and each attribute.
*
* Note: if you consider changing this logic, beware that child rels could
* have zero rows and/or width, if they were excluded by constraints.
@ -377,11 +377,11 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
}
/*
* Note: we could compute appropriate attr_needed data for the
* child's variables, by transforming the parent's attr_needed
* through the translated_vars mapping. However, currently there's
* no need because attr_needed is only examined for base relations
* not otherrels. So we just leave the child's attr_needed empty.
* Note: we could compute appropriate attr_needed data for the child's
* variables, by transforming the parent's attr_needed through the
* translated_vars mapping. However, currently there's no need
* because attr_needed is only examined for base relations not
* otherrels. So we just leave the child's attr_needed empty.
*/
/*
@ -438,7 +438,7 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
rel->rows = parent_rows;
if (parent_rows > 0)
{
int i;
int i;
rel->width = rint(parent_size / parent_rows);
for (i = 0; i < nattrs; i++)
@ -681,6 +681,7 @@ set_cte_pathlist(PlannerInfo *root, RelOptInfo *rel, RangeTblEntry *rte)
if (!cteroot) /* shouldn't happen */
elog(ERROR, "bad levelsup for CTE \"%s\"", rte->ctename);
}
/*
* Note: cte_plan_ids can be shorter than cteList, if we are still working
* on planning the CTEs (ie, this is a side-reference from another CTE).
@ -726,8 +727,8 @@ set_worktable_pathlist(PlannerInfo *root, RelOptInfo *rel, RangeTblEntry *rte)
/*
* We need to find the non-recursive term's plan, which is in the plan
* level that's processing the recursive UNION, which is one level
* *below* where the CTE comes from.
* level that's processing the recursive UNION, which is one level *below*
* where the CTE comes from.
*/
levelsup = rte->ctelevelsup;
if (levelsup == 0) /* shouldn't happen */
@ -1087,7 +1088,7 @@ compare_tlist_datatypes(List *tlist, List *colTypes,
* of rows returned. (This condition is vacuous for DISTINCT, because then
* there are no non-DISTINCT output columns, so we needn't check. But note
* we are assuming that the qual can't distinguish values that the DISTINCT
* operator sees as equal. This is a bit shaky but we have no way to test
* operator sees as equal. This is a bit shaky but we have no way to test
* for the case, and it's unlikely enough that we shouldn't refuse the
* optimization just because it could theoretically happen.)
*
@ -1113,8 +1114,8 @@ qual_is_pushdown_safe(Query *subquery, Index rti, Node *qual,
return false;
/*
* It would be unsafe to push down window function calls, but at least
* for the moment we could never see any in a qual anyhow.
* It would be unsafe to push down window function calls, but at least for
* the moment we could never see any in a qual anyhow.
*/
Assert(!contain_window_function(qual));

36
src/backend/optimizer/path/clausesel.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/clausesel.c,v 1.97 2009/02/06 23:43:23 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/clausesel.c,v 1.98 2009/06/11 14:48:58 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -102,8 +102,8 @@ clauselist_selectivity(PlannerInfo *root,
ListCell *l;
/*
* If there's exactly one clause, then no use in trying to match up
* pairs, so just go directly to clause_selectivity().
* If there's exactly one clause, then no use in trying to match up pairs,
* so just go directly to clause_selectivity().
*/
if (list_length(clauses) == 1)
return clause_selectivity(root, (Node *) linitial(clauses),
@ -410,30 +410,30 @@ treat_as_join_clause(Node *clause, RestrictInfo *rinfo,
if (varRelid != 0)
{
/*
* Caller is forcing restriction mode (eg, because we are examining
* an inner indexscan qual).
* Caller is forcing restriction mode (eg, because we are examining an
* inner indexscan qual).
*/
return false;
}
else if (sjinfo == NULL)
{
/*
* It must be a restriction clause, since it's being evaluated at
* a scan node.
* It must be a restriction clause, since it's being evaluated at a
* scan node.
*/
return false;
}
else
{
/*
* Otherwise, it's a join if there's more than one relation used.
* We can optimize this calculation if an rinfo was passed.
* Otherwise, it's a join if there's more than one relation used. We
* can optimize this calculation if an rinfo was passed.
*
* XXX Since we know the clause is being evaluated at a join,
* the only way it could be single-relation is if it was delayed
* by outer joins. Although we can make use of the restriction
* qual estimators anyway, it seems likely that we ought to account
* for the probability of injected nulls somehow.
* XXX Since we know the clause is being evaluated at a join, the
* only way it could be single-relation is if it was delayed by outer
* joins. Although we can make use of the restriction qual estimators
* anyway, it seems likely that we ought to account for the
* probability of injected nulls somehow.
*/
if (rinfo)
return (bms_membership(rinfo->clause_relids) == BMS_MULTIPLE);
@ -467,7 +467,7 @@ treat_as_join_clause(Node *clause, RestrictInfo *rinfo,
* if the clause isn't a join clause.
*
* sjinfo is NULL for a non-join clause, otherwise it provides additional
* context information about the join being performed. There are some
* context information about the join being performed. There are some
* special cases:
* 1. For a special (not INNER) join, sjinfo is always a member of
* root->join_info_list.
@ -525,7 +525,7 @@ clause_selectivity(PlannerInfo *root,
* contains only vars of that relid --- otherwise varRelid will affect
* the result, so mustn't cache. Outer join quals might be examined
* with either their join's actual jointype or JOIN_INNER, so we need
* two cache variables to remember both cases. Note: we assume the
* two cache variables to remember both cases. Note: we assume the
* result won't change if we are switching the input relations or
* considering a unique-ified case, so we only need one cache variable
* for all non-JOIN_INNER cases.
@ -571,8 +571,8 @@ clause_selectivity(PlannerInfo *root,
{
/*
* A Var at the top of a clause must be a bool Var. This is
* equivalent to the clause reln.attribute = 't', so we
* compute the selectivity as if that is what we have.
* equivalent to the clause reln.attribute = 't', so we compute
* the selectivity as if that is what we have.
*/
s1 = restriction_selectivity(root,
BooleanEqualOperator,

120
src/backend/optimizer/path/costsize.c
View File

@ -54,7 +54,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/costsize.c,v 1.208 2009/05/09 22:51:41 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/costsize.c,v 1.209 2009/06/11 14:48:58 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -126,7 +126,7 @@ static bool adjust_semi_join(PlannerInfo *root, JoinPath *path,
Selectivity *match_count,
bool *indexed_join_quals);
static double approx_tuple_count(PlannerInfo *root, JoinPath *path,
List *quals);
List *quals);
static void set_rel_width(PlannerInfo *root, RelOptInfo *rel);
static double relation_byte_size(double tuples, int width);
static double page_size(double tuples, int width);
@ -946,7 +946,7 @@ cost_valuesscan(Path *path, PlannerInfo *root, RelOptInfo *baserel)
*
* Note: this is used for both self-reference and regular CTEs; the
* possible cost differences are below the threshold of what we could
* estimate accurately anyway. Note that the costs of evaluating the
* estimate accurately anyway. Note that the costs of evaluating the
* referenced CTE query are added into the final plan as initplan costs,
* and should NOT be counted here.
*/
@ -998,9 +998,9 @@ cost_recursive_union(Plan *runion, Plan *nrterm, Plan *rterm)
/*
* We arbitrarily assume that about 10 recursive iterations will be
* needed, and that we've managed to get a good fix on the cost and
* output size of each one of them. These are mighty shaky assumptions
* but it's hard to see how to do better.
* needed, and that we've managed to get a good fix on the cost and output
* size of each one of them. These are mighty shaky assumptions but it's
* hard to see how to do better.
*/
total_cost += 10 * rterm->total_cost;
total_rows += 10 * rterm->plan_rows;
@ -1406,8 +1406,8 @@ cost_nestloop(NestPath *path, PlannerInfo *root, SpecialJoinInfo *sjinfo)
double outer_path_rows = PATH_ROWS(outer_path);
double inner_path_rows = nestloop_inner_path_rows(inner_path);
double ntuples;
Selectivity outer_match_frac;
Selectivity match_count;
Selectivity outer_match_frac;
Selectivity match_count;
bool indexed_join_quals;
if (!enable_nestloop)
@ -1446,7 +1446,7 @@ cost_nestloop(NestPath *path, PlannerInfo *root, SpecialJoinInfo *sjinfo)
&indexed_join_quals))
{
double outer_matched_rows;
Selectivity inner_scan_frac;
Selectivity inner_scan_frac;
/*
* SEMI or ANTI join: executor will stop after first match.
@ -1470,11 +1470,11 @@ cost_nestloop(NestPath *path, PlannerInfo *root, SpecialJoinInfo *sjinfo)
/*
* For unmatched outer-rel rows, there are two cases. If the inner
* path is an indexscan using all the joinquals as indexquals, then
* an unmatched row results in an indexscan returning no rows, which
* is probably quite cheap. We estimate this case as the same cost
* to return the first tuple of a nonempty scan. Otherwise, the
* executor will have to scan the whole inner rel; not so cheap.
* path is an indexscan using all the joinquals as indexquals, then an
* unmatched row results in an indexscan returning no rows, which is
* probably quite cheap. We estimate this case as the same cost to
* return the first tuple of a nonempty scan. Otherwise, the executor
* will have to scan the whole inner rel; not so cheap.
*/
if (indexed_join_quals)
{
@ -1569,7 +1569,7 @@ cost_mergejoin(MergePath *path, PlannerInfo *root, SpecialJoinInfo *sjinfo)
qp_qual_cost.per_tuple -= merge_qual_cost.per_tuple;
/*
* Get approx # tuples passing the mergequals. We use approx_tuple_count
* Get approx # tuples passing the mergequals. We use approx_tuple_count
* here because we need an estimate done with JOIN_INNER semantics.
*/
mergejointuples = approx_tuple_count(root, &path->jpath, mergeclauses);
@ -1586,7 +1586,7 @@ cost_mergejoin(MergePath *path, PlannerInfo *root, SpecialJoinInfo *sjinfo)
* 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
* m2, ...; in the inner relation, n1, n2, ... Then we have
*
* size of join = m1 * n1 + m2 * n2 + ...
*
@ -1620,11 +1620,11 @@ cost_mergejoin(MergePath *path, PlannerInfo *root, SpecialJoinInfo *sjinfo)
* (unless it's an outer join, in which case the outer side has to be
* scanned all the way anyway). Estimate fraction of the left and right
* inputs that will actually need to be scanned. Likewise, we can
* estimate the number of rows that will be skipped before the first
* join pair is found, which should be factored into startup cost.
* We use only the first (most significant) merge clause for this purpose.
* Since mergejoinscansel() is a fairly expensive computation, we cache
* the results in the merge clause RestrictInfo.
* estimate the number of rows that will be skipped before the first join
* pair is found, which should be factored into startup cost. We use only
* the first (most significant) merge clause for this purpose. Since
* mergejoinscansel() is a fairly expensive computation, we cache the
* results in the merge clause RestrictInfo.
*/
if (mergeclauses && path->jpath.jointype != JOIN_FULL)
{
@ -1795,8 +1795,8 @@ cost_mergejoin(MergePath *path, PlannerInfo *root, SpecialJoinInfo *sjinfo)
* clauses that are to be applied at the join. (This is pessimistic since
* not all of the quals may get evaluated at each tuple.)
*
* Note: we could adjust for SEMI/ANTI joins skipping some qual evaluations
* here, but it's probably not worth the trouble.
* Note: we could adjust for SEMI/ANTI joins skipping some qual
* evaluations here, but it's probably not worth the trouble.
*/
startup_cost += qp_qual_cost.startup;
cpu_per_tuple = cpu_tuple_cost + qp_qual_cost.per_tuple;
@ -1890,8 +1890,8 @@ cost_hashjoin(HashPath *path, PlannerInfo *root, SpecialJoinInfo *sjinfo)
int num_skew_mcvs;
double virtualbuckets;
Selectivity innerbucketsize;
Selectivity outer_match_frac;
Selectivity match_count;
Selectivity outer_match_frac;
Selectivity match_count;
ListCell *hcl;
if (!enable_hashjoin)
@ -1937,11 +1937,12 @@ cost_hashjoin(HashPath *path, PlannerInfo *root, SpecialJoinInfo *sjinfo)
*/
ExecChooseHashTableSize(inner_path_rows,
inner_path->parent->width,
true, /* useskew */
true, /* useskew */
&numbuckets,
&numbatches,
&num_skew_mcvs);
virtualbuckets = (double) numbuckets *(double) numbatches;
/* mark the path with estimated # of batches */
path->num_batches = numbatches;
@ -2038,7 +2039,7 @@ cost_hashjoin(HashPath *path, PlannerInfo *root, SpecialJoinInfo *sjinfo)
NULL))
{
double outer_matched_rows;
Selectivity inner_scan_frac;
Selectivity inner_scan_frac;
/*
* SEMI or ANTI join: executor will stop after first match.
@ -2064,12 +2065,12 @@ cost_hashjoin(HashPath *path, PlannerInfo *root, SpecialJoinInfo *sjinfo)
* preferentially hit heavily-populated buckets; instead assume they
* are uncorrelated with the inner distribution and so they see an
* average bucket size of inner_path_rows / virtualbuckets. In the
* second place, it seems likely that they will have few if any
* exact hash-code matches and so very few of the tuples in the
* bucket will actually require eval of the hash quals. We don't
* have any good way to estimate how many will, but for the moment
* assume that the effective cost per bucket entry is one-tenth what
* it is for matchable tuples.
* second place, it seems likely that they will have few if any exact
* hash-code matches and so very few of the tuples in the bucket will
* actually require eval of the hash quals. We don't have any good
* way to estimate how many will, but for the moment assume that the
* effective cost per bucket entry is one-tenth what it is for
* matchable tuples.
*/
run_cost += hash_qual_cost.per_tuple *
(outer_path_rows - outer_matched_rows) *
@ -2151,18 +2152,17 @@ cost_subplan(PlannerInfo *root, SubPlan *subplan, Plan *plan)
/*
* The per-tuple costs include the cost of evaluating the lefthand
* expressions, plus the cost of probing the hashtable. We already
* accounted for the lefthand expressions as part of the testexpr,
* and will also have counted one cpu_operator_cost for each
* comparison operator. That is probably too low for the probing
* cost, but it's hard to make a better estimate, so live with it for
* now.
* accounted for the lefthand expressions as part of the testexpr, and
* will also have counted one cpu_operator_cost for each comparison
* operator. That is probably too low for the probing cost, but it's
* hard to make a better estimate, so live with it for now.
*/
}
else
{
/*
* Otherwise we will be rescanning the subplan output on each
* evaluation. We need to estimate how much of the output we will
* evaluation. We need to estimate how much of the output we will
* actually need to scan. NOTE: this logic should agree with the
* tuple_fraction estimates used by make_subplan() in
* plan/subselect.c.
@ -2315,9 +2315,9 @@ cost_qual_eval_walker(Node *node, cost_qual_eval_context *context)
* Vars and Consts are charged zero, and so are boolean operators (AND,
* OR, NOT). Simplistic, but a lot better than no model at all.
*
* Note that Aggref and WindowFunc nodes are (and should be) treated
* like Vars --- whatever execution cost they have is absorbed into
* plan-node-specific costing. As far as expression evaluation is
* Note that Aggref and WindowFunc nodes are (and should be) treated like
* Vars --- whatever execution cost they have is absorbed into
* plan-node-specific costing. As far as expression evaluation is
* concerned they're just like Vars.
*
* Should we try to account for the possibility of short-circuit
@ -2425,10 +2425,10 @@ cost_qual_eval_walker(Node *node, cost_qual_eval_context *context)
else if (IsA(node, AlternativeSubPlan))
{
/*
* Arbitrarily use the first alternative plan for costing. (We should
* Arbitrarily use the first alternative plan for costing. (We should
* certainly only include one alternative, and we don't yet have
* enough information to know which one the executor is most likely
* to use.)
* enough information to know which one the executor is most likely to
* use.)
*/
AlternativeSubPlan *asplan = (AlternativeSubPlan *) node;
@ -2495,8 +2495,8 @@ adjust_semi_join(PlannerInfo *root, JoinPath *path, SpecialJoinInfo *sjinfo,
*/
/*
* In an ANTI join, we must ignore clauses that are "pushed down",
* since those won't affect the match logic. In a SEMI join, we do not
* In an ANTI join, we must ignore clauses that are "pushed down", since
* those won't affect the match logic. In a SEMI join, we do not
* distinguish joinquals from "pushed down" quals, so just use the whole
* restrictinfo list.
*/
@ -2550,15 +2550,15 @@ adjust_semi_join(PlannerInfo *root, JoinPath *path, SpecialJoinInfo *sjinfo,
/*
* jselec can be interpreted as the fraction of outer-rel rows that have
* any matches (this is true for both SEMI and ANTI cases). And nselec
* is the fraction of the Cartesian product that matches. So, the
* average number of matches for each outer-rel row that has at least
* one match is nselec * inner_rows / jselec.
* any matches (this is true for both SEMI and ANTI cases). And nselec is
* the fraction of the Cartesian product that matches. So, the average
* number of matches for each outer-rel row that has at least one match is
* nselec * inner_rows / jselec.
*
* Note: it is correct to use the inner rel's "rows" count here, not
* PATH_ROWS(), even if the inner path under consideration is an inner
* indexscan. This is because we have included all the join clauses
* in the selectivity estimate, even ones used in an inner indexscan.
* indexscan. This is because we have included all the join clauses in
* the selectivity estimate, even ones used in an inner indexscan.
*/
if (jselec > 0) /* protect against zero divide */
{
@ -2573,10 +2573,9 @@ adjust_semi_join(PlannerInfo *root, JoinPath *path, SpecialJoinInfo *sjinfo,
*match_count = avgmatch;
/*
* If requested, check whether the inner path uses all the joinquals
* as indexquals. (If that's true, we can assume that an unmatched
* outer tuple is cheap to process, whereas otherwise it's probably
* expensive.)
* If requested, check whether the inner path uses all the joinquals as
* indexquals. (If that's true, we can assume that an unmatched outer
* tuple is cheap to process, whereas otherwise it's probably expensive.)
*/
if (indexed_join_quals)
{
@ -2906,8 +2905,8 @@ set_cte_size_estimates(PlannerInfo *root, RelOptInfo *rel, Plan *cteplan)
if (rte->self_reference)
{
/*
* In a self-reference, arbitrarily assume the average worktable
* size is about 10 times the nonrecursive term's size.
* In a self-reference, arbitrarily assume the average worktable size
* is about 10 times the nonrecursive term's size.
*/
rel->tuples = 10 * cteplan->plan_rows;
}
@ -2959,7 +2958,8 @@ set_rel_width(PlannerInfo *root, RelOptInfo *rel)
ndx = var->varattno - rel->min_attr;
/*
* The width probably hasn't been cached yet, but may as well check
* The width probably hasn't been cached yet, but may as well
* check
*/
if (rel->attr_widths[ndx] > 0)
{

40
src/backend/optimizer/path/equivclass.c
View File

@ -10,7 +10,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/equivclass.c,v 1.18 2009/04/19 19:46:33 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/equivclass.c,v 1.19 2009/06/11 14:48:58 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -438,9 +438,9 @@ get_eclass_for_sort_expr(PlannerInfo *root,
/*
* add_eq_member doesn't check for volatile functions, set-returning
* functions, aggregates, or window functions, but such could appear
* in sort expressions; so we have to check whether its const-marking
* was correct.
* functions, aggregates, or window functions, but such could appear in
* sort expressions; so we have to check whether its const-marking was
* correct.
*/
if (newec->ec_has_const)
{
@ -563,11 +563,11 @@ generate_base_implied_equalities_const(PlannerInfo *root,
ListCell *lc;
/*
* In the trivial case where we just had one "var = const" clause,
* push the original clause back into the main planner machinery. There
* is nothing to be gained by doing it differently, and we save the
* effort to re-build and re-analyze an equality clause that will be
* exactly equivalent to the old one.
* In the trivial case where we just had one "var = const" clause, push
* the original clause back into the main planner machinery. There is
* nothing to be gained by doing it differently, and we save the effort to
* re-build and re-analyze an equality clause that will be exactly
* equivalent to the old one.
*/
if (list_length(ec->ec_members) == 2 &&
list_length(ec->ec_sources) == 1)
@ -1166,7 +1166,7 @@ create_join_clause(PlannerInfo *root,
*
* Outer join clauses that are marked outerjoin_delayed are special: this
* condition means that one or both VARs might go to null due to a lower
* outer join. We can still push a constant through the clause, but only
* outer join. We can still push a constant through the clause, but only
* if its operator is strict; and we *have to* throw the clause back into
* regular joinclause processing. By keeping the strict join clause,
* we ensure that any null-extended rows that are mistakenly generated due
@ -1816,11 +1816,11 @@ have_relevant_eclass_joinclause(PlannerInfo *root,
* path to look through ec_sources. Checking the members anyway is OK
* as a possibly-overoptimistic heuristic.
*
* We don't test ec_has_const either, even though a const eclass
* won't generate real join clauses. This is because if we had
* "WHERE a.x = b.y and a.x = 42", it is worth considering a join
* between a and b, since the join result is likely to be small even
* though it'll end up being an unqualified nestloop.
* We don't test ec_has_const either, even though a const eclass won't
* generate real join clauses. This is because if we had "WHERE a.x =
* b.y and a.x = 42", it is worth considering a join between a and b,
* since the join result is likely to be small even though it'll end
* up being an unqualified nestloop.
*/
/* Needn't scan if it couldn't contain members from each rel */
@ -1890,11 +1890,11 @@ has_relevant_eclass_joinclause(PlannerInfo *root, RelOptInfo *rel1)
* path to look through ec_sources. Checking the members anyway is OK
* as a possibly-overoptimistic heuristic.
*
* We don't test ec_has_const either, even though a const eclass
* won't generate real join clauses. This is because if we had
* "WHERE a.x = b.y and a.x = 42", it is worth considering a join
* between a and b, since the join result is likely to be small even
* though it'll end up being an unqualified nestloop.
* We don't test ec_has_const either, even though a const eclass won't
* generate real join clauses. This is because if we had "WHERE a.x =
* b.y and a.x = 42", it is worth considering a join between a and b,
* since the join result is likely to be small even though it'll end
* up being an unqualified nestloop.
*/
/* Needn't scan if it couldn't contain members from each rel */

40
src/backend/optimizer/path/indxpath.c
View File

@ -9,7 +9,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.239 2009/04/16 20:42:16 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.240 2009/06/11 14:48:58 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -179,14 +179,14 @@ create_index_paths(PlannerInfo *root, RelOptInfo *rel)
true, NULL, SAOP_FORBID, ST_ANYSCAN);
/*
* Submit all the ones that can form plain IndexScan plans to add_path.
* (A plain IndexPath always represents a plain IndexScan plan; however
* some of the indexes might support only bitmap scans, and those we
* mustn't submit to add_path here.) Also, pick out the ones that might
* be useful as bitmap scans. For that, we must discard indexes that
* don't support bitmap scans, and we also are only interested in paths
* that have some selectivity; we should discard anything that was
* generated solely for ordering purposes.
* Submit all the ones that can form plain IndexScan plans to add_path. (A
* plain IndexPath always represents a plain IndexScan plan; however some
* of the indexes might support only bitmap scans, and those we mustn't
* submit to add_path here.) Also, pick out the ones that might be useful
* as bitmap scans. For that, we must discard indexes that don't support
* bitmap scans, and we also are only interested in paths that have some
* selectivity; we should discard anything that was generated solely for
* ordering purposes.
*/
bitindexpaths = NIL;
foreach(l, indexpaths)
@ -1628,13 +1628,13 @@ eclass_matches_any_index(EquivalenceClass *ec, EquivalenceMember *em,
/*
* If it's a btree index, we can reject it if its opfamily isn't
* compatible with the EC, since no clause generated from the
* EC could be used with the index. For non-btree indexes,
* we can't easily tell whether clauses generated from the EC
* could be used with the index, so only check for expression
* match. This might mean we return "true" for a useless index,
* but that will just cause some wasted planner cycles; it's
* better than ignoring useful indexes.
* compatible with the EC, since no clause generated from the EC
* could be used with the index. For non-btree indexes, we can't
* easily tell whether clauses generated from the EC could be used
* with the index, so only check for expression match. This might
* mean we return "true" for a useless index, but that will just
* cause some wasted planner cycles; it's better than ignoring
* useful indexes.
*/
if ((index->relam != BTREE_AM_OID ||
list_member_oid(ec->ec_opfamilies, curFamily)) &&
@ -2223,9 +2223,9 @@ match_special_index_operator(Expr *clause, Oid opfamily,
* want to apply. (A hash index, for example, will not support ">=".)
* Currently, only btree supports the operators we need.
*
* Note: actually, in the Pattern_Prefix_Exact case, we only need "="
* so a hash index would work. Currently it doesn't seem worth checking
* for that, however.
* Note: actually, in the Pattern_Prefix_Exact case, we only need "=" so a
* hash index would work. Currently it doesn't seem worth checking for
* that, however.
*
* We insist on the opfamily being the specific one we expect, else we'd
* do the wrong thing if someone were to make a reverse-sort opfamily with
@ -2460,7 +2460,7 @@ expand_indexqual_opclause(RestrictInfo *rinfo, Oid opfamily)
/*
* LIKE and regex operators are not members of any btree index opfamily,
* but they can be members of opfamilies for more exotic index types such
* as GIN. Therefore, we should only do expansion if the operator is
* as GIN. Therefore, we should only do expansion if the operator is
* actually not in the opfamily. But checking that requires a syscache
* lookup, so it's best to first see if the operator is one we are
* interested in.

16
src/backend/optimizer/path/joinpath.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.121 2009/02/05 01:24:55 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.122 2009/06/11 14:48:59 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -1022,14 +1022,14 @@ select_mergejoin_clauses(PlannerInfo *root,
* Note: it would be bad if this condition failed for an otherwise
* mergejoinable FULL JOIN clause, since that would result in
* undesirable planner failure. I believe that is not possible
* however; a variable involved in a full join could only appear
* in below_outer_join eclasses, which aren't considered redundant.
* however; a variable involved in a full join could only appear in
* below_outer_join eclasses, which aren't considered redundant.
*
* This case *can* happen for left/right join clauses: the
* outer-side variable could be equated to a constant. Because we
* will propagate that constant across the join clause, the loss of
* ability to do a mergejoin is not really all that big a deal, and
* so it's not clear that improving this is important.
* This case *can* happen for left/right join clauses: the outer-side
* variable could be equated to a constant. Because we will propagate
* that constant across the join clause, the loss of ability to do a
* mergejoin is not really all that big a deal, and so it's not clear
* that improving this is important.
*/
cache_mergeclause_eclasses(root, restrictinfo);

37
src/backend/optimizer/path/joinrels.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.99 2009/02/27 22:41:37 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.100 2009/06/11 14:48:59 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -353,7 +353,7 @@ join_is_legal(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
ListCell *l;
/*
* Ensure output params are set on failure return. This is just to
* Ensure output params are set on failure return. This is just to
* suppress uninitialized-variable warnings from overly anal compilers.
*/
*sjinfo_p = NULL;
@ -361,7 +361,7 @@ join_is_legal(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
/*
* If we have any special joins, the proposed join might be illegal; and
* in any case we have to determine its join type. Scan the join info
* in any case we have to determine its join type. Scan the join info
* list for conflicts.
*/
match_sjinfo = NULL;
@ -569,7 +569,7 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
/*
* If it's a plain inner join, then we won't have found anything in
* join_info_list. Make up a SpecialJoinInfo so that selectivity
* join_info_list. Make up a SpecialJoinInfo so that selectivity
* estimation functions will know what's being joined.
*/
if (sjinfo == NULL)
@ -595,8 +595,8 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
&restrictlist);
/*
* If we've already proven this join is empty, we needn't consider
* any more paths for it.
* If we've already proven this join is empty, we needn't consider any
* more paths for it.
*/
if (is_dummy_rel(joinrel))
{
@ -605,19 +605,19 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
}
/*
* Consider paths using each rel as both outer and inner. Depending
* on the join type, a provably empty outer or inner rel might mean
* the join is provably empty too; in which case throw away any
* previously computed paths and mark the join as dummy. (We do it
* this way since it's conceivable that dummy-ness of a multi-element
* join might only be noticeable for certain construction paths.)
* Consider paths using each rel as both outer and inner. Depending on
* the join type, a provably empty outer or inner rel might mean the join
* is provably empty too; in which case throw away any previously computed
* paths and mark the join as dummy. (We do it this way since it's
* conceivable that dummy-ness of a multi-element join might only be
* noticeable for certain construction paths.)
*
* Also, a provably constant-false join restriction typically means that
* we can skip evaluating one or both sides of the join. We do this
* by marking the appropriate rel as dummy.
* we can skip evaluating one or both sides of the join. We do this by
* marking the appropriate rel as dummy.
*
* We need only consider the jointypes that appear in join_info_list,
* plus JOIN_INNER.
* We need only consider the jointypes that appear in join_info_list, plus
* JOIN_INNER.
*/
switch (sjinfo->jointype)
{
@ -665,6 +665,7 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2)
restrictlist);
break;
case JOIN_SEMI:
/*
* We might have a normal semijoin, or a case where we don't have
* enough rels to do the semijoin but can unique-ify the RHS and
@ -971,12 +972,12 @@ restriction_is_constant_false(List *restrictlist)
*/
foreach(lc, restrictlist)
{
RestrictInfo *rinfo = (RestrictInfo *) lfirst(lc);
RestrictInfo *rinfo = (RestrictInfo *) lfirst(lc);
Assert(IsA(rinfo, RestrictInfo));
if (rinfo->clause && IsA(rinfo->clause, Const))
{
Const *con = (Const *) rinfo->clause;
Const *con = (Const *) rinfo->clause;
/* constant NULL is as good as constant FALSE for our purposes */
if (con->constisnull)

6
src/backend/optimizer/path/orindxpath.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/orindxpath.c,v 1.89 2009/04/16 20:42:16 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/orindxpath.c,v 1.90 2009/06/11 14:48:59 momjian Exp $
*
*-------------------------------------------------------------------------
*/
@ -96,10 +96,10 @@ create_or_index_quals(PlannerInfo *root, RelOptInfo *rel)
* enforced at the relation scan level.
*
* We must also ignore clauses that are marked !is_pushed_down (ie they
* are themselves outer-join clauses). It would be safe to extract an
* are themselves outer-join clauses). It would be safe to extract an
* index condition from such a clause if we are within the nullable rather
* than the non-nullable side of its join, but we haven't got enough
* context here to tell which applies. OR clauses in outer-join quals
* context here to tell which applies. OR clauses in outer-join quals
* aren't exactly common, so we'll let that case go unoptimized for now.
*/
foreach(i, rel->joininfo)