diff options
Diffstat (limited to 'src/backend/optimizer/path/indxpath.c')
| -rw-r--r-- | src/backend/optimizer/path/indxpath.c | 76 |
1 files changed, 38 insertions, 38 deletions
diff --git a/src/backend/optimizer/path/indxpath.c b/src/backend/optimizer/path/indxpath.c index a912174fb00..42dcb111aeb 100644 --- a/src/backend/optimizer/path/indxpath.c +++ b/src/backend/optimizer/path/indxpath.c @@ -222,7 +222,7 @@ static Const *string_to_const(const char *str, Oid datatype); * Note: in cases involving LATERAL references in the relation's tlist, it's * possible that rel->lateral_relids is nonempty. Currently, we include * lateral_relids into the parameterization reported for each path, but don't - * take it into account otherwise. The fact that any such rels *must* be + * take it into account otherwise. The fact that any such rels *must* be * available as parameter sources perhaps should influence our choices of * index quals ... but for now, it doesn't seem worth troubling over. * In particular, comments below about "unparameterized" paths should be read @@ -270,7 +270,7 @@ create_index_paths(PlannerInfo *root, RelOptInfo *rel) match_restriction_clauses_to_index(rel, index, &rclauseset); /* - * Build index paths from the restriction clauses. These will be + * Build index paths from the restriction clauses. These will be * non-parameterized paths. Plain paths go directly to add_path(), * bitmap paths are added to bitindexpaths to be handled below. */ @@ -278,10 +278,10 @@ create_index_paths(PlannerInfo *root, RelOptInfo *rel) &bitindexpaths); /* - * Identify the join clauses that can match the index. For the moment - * we keep them separate from the restriction clauses. Note that this + * Identify the join clauses that can match the index. For the moment + * we keep them separate from the restriction clauses. Note that this * step finds only "loose" join clauses that have not been merged into - * EquivalenceClasses. Also, collect join OR clauses for later. + * EquivalenceClasses. Also, collect join OR clauses for later. */ MemSet(&jclauseset, 0, sizeof(jclauseset)); match_join_clauses_to_index(root, rel, index, @@ -343,9 +343,9 @@ create_index_paths(PlannerInfo *root, RelOptInfo *rel) /* * Likewise, if we found anything usable, generate BitmapHeapPaths for the - * most promising combinations of join bitmap index paths. Our strategy + * most promising combinations of join bitmap index paths. Our strategy * is to generate one such path for each distinct parameterization seen - * among the available bitmap index paths. This may look pretty + * among the available bitmap index paths. This may look pretty * expensive, but usually there won't be very many distinct * parameterizations. (This logic is quite similar to that in * consider_index_join_clauses, but we're working with whole paths not @@ -461,7 +461,7 @@ consider_index_join_clauses(PlannerInfo *root, RelOptInfo *rel, * * For simplicity in selecting relevant clauses, we represent each set of * outer rels as a maximum set of clause_relids --- that is, the indexed - * relation itself is also included in the relids set. considered_relids + * relation itself is also included in the relids set. considered_relids * lists all relids sets we've already tried. */ for (indexcol = 0; indexcol < index->ncolumns; indexcol++) @@ -550,7 +550,7 @@ consider_index_join_outer_rels(PlannerInfo *root, RelOptInfo *rel, /* * If this clause was derived from an equivalence class, the * clause list may contain other clauses derived from the same - * eclass. We should not consider that combining this clause with + * eclass. We should not consider that combining this clause with * one of those clauses generates a usefully different * parameterization; so skip if any clause derived from the same * eclass would already have been included when using oldrelids. @@ -633,9 +633,9 @@ get_join_index_paths(PlannerInfo *root, RelOptInfo *rel, } /* - * Add applicable eclass join clauses. The clauses generated for each + * Add applicable eclass join clauses. The clauses generated for each * column are redundant (cf generate_implied_equalities_for_column), - * so we need at most one. This is the only exception to the general + * so we need at most one. This is the only exception to the general * rule of using all available index clauses. */ foreach(lc, eclauseset->indexclauses[indexcol]) @@ -722,7 +722,7 @@ bms_equal_any(Relids relids, List *relids_list) * bitmap indexpaths are added to *bitindexpaths for later processing. * * This is a fairly simple frontend to build_index_paths(). Its reason for - * existence is mainly to handle ScalarArrayOpExpr quals properly. If the + * existence is mainly to handle ScalarArrayOpExpr quals properly. If the * index AM supports them natively, we should just include them in simple * index paths. If not, we should exclude them while building simple index * paths, and then make a separate attempt to include them in bitmap paths. @@ -736,7 +736,7 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel, ListCell *lc; /* - * Build simple index paths using the clauses. Allow ScalarArrayOpExpr + * Build simple index paths using the clauses. Allow ScalarArrayOpExpr * clauses only if the index AM supports them natively. */ indexpaths = build_index_paths(root, rel, @@ -748,7 +748,7 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel, * Submit all the ones that can form plain IndexScan plans to add_path. (A * plain IndexPath can represent either a plain IndexScan or an * IndexOnlyScan, but for our purposes here that distinction does not - * matter. However, some of the indexes might support only bitmap scans, + * matter. 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 are usable as bitmap scans. For that, we @@ -792,7 +792,7 @@ get_index_paths(PlannerInfo *root, RelOptInfo *rel, * We return a list of paths because (1) this routine checks some cases * that should cause us to not generate any IndexPath, and (2) in some * cases we want to consider both a forward and a backward scan, so as - * to obtain both sort orders. Note that the paths are just returned + * to obtain both sort orders. Note that the paths are just returned * to the caller and not immediately fed to add_path(). * * At top level, useful_predicate should be exactly the index's predOK flag @@ -975,7 +975,7 @@ build_index_paths(PlannerInfo *root, RelOptInfo *rel, } /* - * 3. Check if an index-only scan is possible. If we're not building + * 3. Check if an index-only scan is possible. If we're not building * plain indexscans, this isn't relevant since bitmap scans don't support * index data retrieval anyway. */ @@ -1080,13 +1080,13 @@ build_paths_for_OR(PlannerInfo *root, RelOptInfo *rel, continue; /* - * Ignore partial indexes that do not match the query. If a partial + * Ignore partial indexes that do not match the query. If a partial * index is marked predOK then we know it's OK. Otherwise, we have to * test whether the added clauses are sufficient to imply the * predicate. If so, we can 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 + * 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.) @@ -1256,7 +1256,7 @@ generate_bitmap_or_paths(PlannerInfo *root, RelOptInfo *rel, * Given a nonempty list of bitmap paths, AND them into one path. * * This is a nontrivial decision since we can legally use any subset of the - * given path set. We want to choose a good tradeoff between selectivity + * given path set. We want to choose a good tradeoff between selectivity * and cost of computing the bitmap. * * The result is either a single one of the inputs, or a BitmapAndPath @@ -1283,12 +1283,12 @@ choose_bitmap_and(PlannerInfo *root, RelOptInfo *rel, List *paths) * In theory we should consider every nonempty subset of the given paths. * In practice that seems like overkill, given the crude nature of the * estimates, not to mention the possible effects of higher-level AND and - * OR clauses. Moreover, it's completely impractical if there are a large + * OR clauses. Moreover, it's completely impractical if there are a large * number of paths, since the work would grow as O(2^N). * * As a heuristic, we first check for paths using exactly the same sets of * WHERE clauses + index predicate conditions, and reject all but the - * cheapest-to-scan in any such group. This primarily gets rid of indexes + * cheapest-to-scan in any such group. This primarily gets rid of indexes * that include the interesting columns but also irrelevant columns. (In * situations where the DBA has gone overboard on creating variant * indexes, this can make for a very large reduction in the number of @@ -1308,7 +1308,7 @@ choose_bitmap_and(PlannerInfo *root, RelOptInfo *rel, List *paths) * costsize.c and clausesel.c aren't very smart about redundant clauses. * They will usually double-count the redundant clauses, producing a * too-small selectivity that makes a redundant AND step look like it - * reduces the total cost. Perhaps someday that code will be smarter and + * reduces the total cost. Perhaps someday that code will be smarter and * we can remove this limitation. (But note that this also defends * against flat-out duplicate input paths, which can happen because * match_join_clauses_to_index will find the same OR join clauses that @@ -1316,7 +1316,7 @@ choose_bitmap_and(PlannerInfo *root, RelOptInfo *rel, List *paths) * of.) * * For the same reason, we reject AND combinations in which an index - * predicate clause duplicates another clause. Here we find it necessary + * predicate clause duplicates another clause. Here we find it necessary * to be even stricter: we'll reject a partial index if any of its * predicate clauses are implied by the set of WHERE clauses and predicate * clauses used so far. This covers cases such as a condition "x = 42" @@ -1379,7 +1379,7 @@ choose_bitmap_and(PlannerInfo *root, RelOptInfo *rel, List *paths) /* * For each surviving index, consider it as an "AND group leader", and see * whether adding on any of the later indexes results in an AND path with - * cheaper total cost than before. Then take the cheapest AND group. + * cheaper total cost than before. Then take the cheapest AND group. */ for (i = 0; i < npaths; i++) { @@ -1711,7 +1711,7 @@ find_indexpath_quals(Path *bitmapqual, List **quals, List **preds) /* * find_list_position * Return the given node's position (counting from 0) in the given - * list of nodes. If it's not equal() to any existing list member, + * list of nodes. If it's not equal() to any existing list member, * add it at the end, and return that position. */ static int @@ -1817,7 +1817,7 @@ check_index_only(RelOptInfo *rel, IndexOptInfo *index) * Since we produce parameterized paths before we've begun to generate join * relations, it's impossible to predict exactly how many times a parameterized * path will be iterated; we don't know the size of the relation that will be - * on the outside of the nestloop. However, we should try to account for + * on the outside of the nestloop. However, we should try to account for * multiple iterations somehow in costing the path. The heuristic embodied * here is to use the rowcount of the smallest other base relation needed in * the join clauses used by the path. (We could alternatively consider the @@ -2032,7 +2032,7 @@ match_clause_to_index(IndexOptInfo *index, * doesn't involve a volatile function or a Var of the index's relation. * In particular, Vars belonging to other relations of the query are * accepted here, since a clause of that form can be used in a - * parameterized indexscan. It's the responsibility of higher code levels + * parameterized indexscan. It's the responsibility of higher code levels * to manage restriction and join clauses appropriately. * * Note: we do need to check for Vars of the index's relation on the @@ -2056,7 +2056,7 @@ match_clause_to_index(IndexOptInfo *index, * It is also possible to match RowCompareExpr clauses to indexes (but * currently, only btree indexes handle this). In this routine we will * report a match if the first column of the row comparison matches the - * target index column. This is sufficient to guarantee that some index + * target index column. This is sufficient to guarantee that some index * condition can be constructed from the RowCompareExpr --- whether the * remaining columns match the index too is considered in * adjust_rowcompare_for_index(). @@ -2094,7 +2094,7 @@ match_clause_to_indexcol(IndexOptInfo *index, bool plain_op; /* - * Never match pseudoconstants to indexes. (Normally this could not + * Never match pseudoconstants to indexes. (Normally this could not * happen anyway, since a pseudoconstant clause couldn't contain a Var, * but what if someone builds an expression index on a constant? It's not * totally unreasonable to do so with a partial index, either.) @@ -2378,7 +2378,7 @@ match_pathkeys_to_index(IndexOptInfo *index, List *pathkeys, * We allow any column of the index to match each pathkey; they * don't have to match left-to-right as you might expect. This is * correct for GiST, which is the sole existing AM supporting - * amcanorderbyop. We might need different logic in future for + * amcanorderbyop. We might need different logic in future for * other implementations. */ for (indexcol = 0; indexcol < index->ncolumns; indexcol++) @@ -2429,7 +2429,7 @@ match_pathkeys_to_index(IndexOptInfo *index, List *pathkeys, * Note that we currently do not consider the collation of the ordering * operator's result. In practical cases the result type will be numeric * and thus have no collation, and it's not very clear what to match to - * if it did have a collation. The index's collation should match the + * if it did have a collation. The index's collation should match the * ordering operator's input collation, not its result. * * If successful, return 'clause' as-is if the indexkey is on the left, @@ -2679,7 +2679,7 @@ ec_member_matches_indexcol(PlannerInfo *root, RelOptInfo *rel, * if it is true. * 2. A list of expressions in this relation, and a corresponding list of * equality operators. The caller must have already checked that the operators - * represent equality. (Note: the operators could be cross-type; the + * represent equality. (Note: the operators could be cross-type; the * expressions should correspond to their RHS inputs.) * * The caller need only supply equality conditions arising from joins; @@ -2868,7 +2868,7 @@ match_index_to_operand(Node *operand, int indkey; /* - * Ignore any RelabelType node above the operand. This is needed to be + * Ignore any RelabelType node above the operand. This is needed to be * able to apply indexscanning in binary-compatible-operator cases. Note: * we can assume there is at most one RelabelType node; * eval_const_expressions() will have simplified if more than one. @@ -2935,10 +2935,10 @@ match_index_to_operand(Node *operand, * indexscan machinery. The key idea is that these operators allow us * to derive approximate indexscan qual clauses, such that any tuples * that pass the operator clause itself must also satisfy the simpler - * indexscan condition(s). Then we can use the indexscan machinery + * indexscan condition(s). Then we can use the indexscan machinery * to avoid scanning as much of the table as we'd otherwise have to, * while applying the original operator as a qpqual condition to ensure - * we deliver only the tuples we want. (In essence, we're using a regular + * we deliver only the tuples we want. (In essence, we're using a regular * index as if it were a lossy index.) * * An example of what we're doing is @@ -2952,7 +2952,7 @@ match_index_to_operand(Node *operand, * * Another thing that we do with this machinery is to provide special * smarts for "boolean" indexes (that is, indexes on boolean columns - * that support boolean equality). We can transform a plain reference + * that support boolean equality). We can transform a plain reference * to the indexkey into "indexkey = true", or "NOT indexkey" into * "indexkey = false", so as to make the expression indexable using the * regular index operators. (As of Postgres 8.1, we must do this here @@ -3374,7 +3374,7 @@ expand_indexqual_opclause(RestrictInfo *rinfo, Oid opfamily, Oid idxcollation) /* * 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. @@ -3492,7 +3492,7 @@ expand_indexqual_rowcompare(RestrictInfo *rinfo, * column matches) or a simple OpExpr (if the first-column match is all * there is). In these cases the modified clause is always "<=" or ">=" * even when the original was "<" or ">" --- this is necessary to match all - * the rows that could match the original. (We are essentially building a + * the rows that could match the original. (We are essentially building a * lossy version of the row comparison when we do this.) * * *indexcolnos receives an integer list of the index column numbers (zero |