| blob | e7237ce7728b35d9400676cb0edc6518896a18a9 |
1 /*-------------------------------------------------------------------------
2 *
3 * indxpath.c
4 * Routines to determine which indexes are usable for scanning a
5 * given relation, and create Paths accordingly.
6 *
7 * Portions Copyright (c) 1996-2008, PostgreSQL Global Development Group
8 * Portions Copyright (c) 1994, Regents of the University of California
9 *
10 *
11 * IDENTIFICATION
12 * $PostgreSQL$
13 *
14 *-------------------------------------------------------------------------
15 */
18 #include <math.h>
39 /*
40 * DoneMatchingIndexKeys() - MACRO
41 */
42 #define DoneMatchingIndexKeys(families) (families[0] == InvalidOid)
44 #define IsBooleanOpfamily(opfamily) \
45 ((opfamily) == BOOL_BTREE_FAM_OID || (opfamily) == BOOL_HASH_FAM_OID)
48 /* Per-path data used within choose_bitmap_and() */
50 {
61 SaOpControl saop_control);
79 Relids outer_relids,
80 SaOpControl saop_control);
85 Oid opfamily,
87 Relids outer_relids);
90 Relids outer_relids);
106 Datum rightop);
111 /*
112 * create_index_paths()
113 * Generate all interesting index paths for the given relation.
114 * Candidate paths are added to the rel's pathlist (using add_path).
115 *
116 * To be considered for an index scan, an index must match one or more
117 * restriction clauses or join clauses from the query's qual condition,
118 * or match the query's ORDER BY condition, or have a predicate that
119 * matches the query's qual condition.
120 *
121 * There are two basic kinds of index scans. A "plain" index scan uses
122 * only restriction clauses (possibly none at all) in its indexqual,
123 * so it can be applied in any context. An "innerjoin" index scan uses
124 * join clauses (plus restriction clauses, if available) in its indexqual.
125 * Therefore it can only be used as the inner relation of a nestloop
126 * join against an outer rel that includes all the other rels mentioned
127 * in its join clauses. In that context, values for the other rels'
128 * attributes are available and fixed during any one scan of the indexpath.
129 *
130 * An IndexPath is generated and submitted to add_path() for each plain index
131 * scan this routine deems potentially interesting for the current query.
132 *
133 * We also determine the set of other relids that participate in join
134 * clauses that could be used with each index. The actually best innerjoin
135 * path will be generated for each outer relation later on, but knowing the
136 * set of potential otherrels allows us to identify equivalent outer relations
137 * and avoid repeated computation.
138 *
139 * 'rel' is the relation for which we want to generate index paths
140 *
141 * Note: check_partial_indexes() must have been run previously for this rel.
142 */
143 void
145 {
150 /* Skip the whole mess if no indexes */
152 {
155 }
157 /*
158 * Examine join clauses to see which ones are potentially usable with
159 * indexes of this rel, and generate the set of all other relids that
160 * participate in such join clauses. We'll use this set later to
161 * recognize outer rels that are equivalent for joining purposes.
162 */
165 /*
166 * Find all the index paths that are directly usable for this relation
167 * (ie, are valid without considering OR or JOIN clauses).
168 */
173 /*
174 * We can submit them all to add_path. (This generates access paths for
175 * plain IndexScan plans.) However, for the next step we will only want
176 * the ones that have some selectivity; we must discard anything that was
177 * generated solely for ordering purposes.
178 */
181 {
189 }
191 /*
192 * Generate BitmapOrPaths for any suitable OR-clauses present in the
193 * restriction list. Add these to bitindexpaths.
194 */
197 NULL);
200 /*
201 * Likewise, generate paths using ScalarArrayOpExpr clauses; these can't
202 * be simple indexscans but they can be used in bitmap scans.
203 */
209 /*
210 * If we found anything usable, generate a BitmapHeapPath for the most
211 * promising combination of bitmap index paths.
212 */
214 {
221 }
222 }
225 /*----------
226 * find_usable_indexes
227 * Given a list of restriction clauses, find all the potentially usable
228 * indexes for the given relation, and return a list of IndexPaths.
229 *
230 * The caller actually supplies two lists of restriction clauses: some
231 * "current" ones and some "outer" ones. Both lists can be used freely
232 * to match keys of the index, but an index must use at least one of the
233 * "current" clauses to be considered usable. The motivation for this is
234 * examples like
235 * WHERE (x = 42) AND (... OR (y = 52 AND z = 77) OR ....)
236 * While we are considering the y/z subclause of the OR, we can use "x = 42"
237 * as one of the available index conditions; but we shouldn't match the
238 * subclause to any index on x alone, because such a Path would already have
239 * been generated at the upper level. So we could use an index on x,y,z
240 * or an index on x,y for the OR subclause, but not an index on just x.
241 * When dealing with a partial index, a match of the index predicate to
242 * one of the "current" clauses also makes the index usable.
243 *
244 * If istoplevel is true (indicating we are considering the top level of a
245 * rel's restriction clauses), we will include indexes in the result that
246 * have an interesting sort order, even if they have no matching restriction
247 * clauses.
248 *
249 * 'rel' is the relation for which we want to generate index paths
250 * 'clauses' is the current list of clauses (RestrictInfo nodes)
251 * 'outer_clauses' is the list of additional upper-level clauses
252 * 'istoplevel' is true if clauses are the rel's top-level restriction list
253 * (outer_clauses must be NIL when this is true)
254 * 'outer_rel' is the outer side of the join if forming an inner indexscan
255 * (so some of the given clauses are join clauses); NULL if not
256 * 'saop_control' indicates whether ScalarArrayOpExpr clauses can be used
257 *
258 * Note: check_partial_indexes() must have been run previously.
259 *----------
260 */
265 SaOpControl saop_control)
266 {
274 {
284 /*
285 * Ignore partial indexes that do not match the query. If a partial
286 * index is marked predOK then we know it's OK; otherwise, if we are
287 * at top level we know it's not OK (since predOK is exactly whether
288 * its predicate could be proven from the toplevel clauses).
289 * Otherwise, we have to test whether the added clauses are sufficient
290 * to imply the predicate. If so, we could use the index in the
291 * current context.
292 *
293 * We set useful_predicate to true iff the predicate was proven using
294 * the current set of clauses. This is needed to prevent matching a
295 * predOK index to an arm of an OR, which would be a legal but
296 * pointlessly inefficient plan. (A better plan will be generated by
297 * just scanning the predOK index alone, no OR.)
298 */
301 {
303 {
305 {
306 /* we know predicate was proven from these clauses */
308 }
309 }
310 else
311 {
315 /* Form all_clauses if not done already */
318 outer_clauses);
325 }
326 }
328 /*
329 * 1. Match the index against the available restriction clauses.
330 * found_clause is set true only if at least one of the current
331 * clauses was used (and, if saop_control is SAOP_REQUIRE, it has to
332 * have been a ScalarArrayOpExpr clause).
333 */
335 clauses,
336 outer_clauses,
337 outer_relids,
338 saop_control,
341 /*
342 * Not all index AMs support scans with no restriction clauses. We
343 * can't generate a scan over an index with amoptionalkey = false
344 * unless there's at least one restriction clause.
345 */
349 /*
350 * 2. Compute pathkeys describing index's ordering, if any, then see
351 * how many of them are actually useful for this query. This is not
352 * relevant unless we are at top level.
353 */
357 {
359 ForwardScanDirection);
361 index_pathkeys);
362 }
363 else
366 /*
367 * 3. Generate an indexscan path if there are relevant restriction
368 * clauses in the current clauses, OR the index ordering is
369 * potentially useful for later merging or final output ordering, OR
370 * the index has a predicate that was proven by the current clauses.
371 */
373 {
375 restrictclauses,
376 useful_pathkeys,
377 index_is_ordered ?
378 ForwardScanDirection :
379 NoMovementScanDirection,
380 outer_rel);
382 }
384 /*
385 * 4. If the index is ordered, a backwards scan might be interesting.
386 * Again, this is only interesting at top level.
387 */
390 {
392 BackwardScanDirection);
394 index_pathkeys);
396 {
398 restrictclauses,
399 useful_pathkeys,
400 BackwardScanDirection,
401 outer_rel);
403 }
404 }
405 }
408 }
411 /*
412 * find_saop_paths
413 * Find all the potential indexpaths that make use of ScalarArrayOpExpr
414 * clauses. The executor only supports these in bitmap scans, not
415 * plain indexscans, so we need to segregate them from the normal case.
416 * Otherwise, same API as find_usable_indexes().
417 * Returns a list of IndexPaths.
418 */
423 {
427 /*
428 * Since find_usable_indexes is relatively expensive, don't bother to run
429 * it unless there are some top-level ScalarArrayOpExpr clauses.
430 */
432 {
437 {
440 }
441 }
448 SAOP_REQUIRE);
449 }
452 /*
453 * generate_bitmap_or_paths
454 * Look through the list of clauses to find OR clauses, and generate
455 * a BitmapOrPath for each one we can handle that way. Return a list
456 * of the generated BitmapOrPaths.
457 *
458 * outer_clauses is a list of additional clauses that can be assumed true
459 * for the purpose of generating indexquals, but are not to be searched for
460 * ORs. (See find_usable_indexes() for motivation.) outer_rel is the outer
461 * side when we are considering a nestloop inner indexpath.
462 */
463 List *
467 {
472 /*
473 * We can use both the current and outer clauses as context for
474 * find_usable_indexes
475 */
479 {
486 /* Ignore RestrictInfos that aren't ORs */
490 /*
491 * We must be able to match at least one index to each of the arms of
492 * the OR, else we can't use it.
493 */
496 {
500 /* OR arguments should be ANDs or sub-RestrictInfos */
502 {
506 andargs,
507 all_clauses,
509 outer_rel,
510 SAOP_ALLOW);
511 /* Recurse in case there are sub-ORs */
514 andargs,
515 all_clauses,
516 outer_rel));
517 }
518 else
519 {
524 all_clauses,
526 outer_rel,
527 SAOP_ALLOW);
528 }
530 /*
531 * If nothing matched this arm, we can't do anything with this OR
532 * clause.
533 */
535 {
538 }
540 /*
541 * OK, pick the most promising AND combination, and add it to
542 * pathlist.
543 */
546 }
548 /*
549 * If we have a match for every arm, then turn them into a
550 * BitmapOrPath, and add to result list.
551 */
553 {
556 }
557 }
560 }
563 /*
564 * choose_bitmap_and
565 * Given a nonempty list of bitmap paths, AND them into one path.
566 *
567 * This is a nontrivial decision since we can legally use any subset of the
568 * given path set. We want to choose a good tradeoff between selectivity
569 * and cost of computing the bitmap.
570 *
571 * The result is either a single one of the inputs, or a BitmapAndPath
572 * combining multiple inputs.
573 */
577 {
585 j;
592 /*
593 * In theory we should consider every nonempty subset of the given paths.
594 * In practice that seems like overkill, given the crude nature of the
595 * estimates, not to mention the possible effects of higher-level AND and
596 * OR clauses. Moreover, it's completely impractical if there are a large
597 * number of paths, since the work would grow as O(2^N).
598 *
599 * As a heuristic, we first check for paths using exactly the same sets of
600 * WHERE clauses + index predicate conditions, and reject all but the
601 * cheapest-to-scan in any such group. This primarily gets rid of indexes
602 * that include the interesting columns but also irrelevant columns. (In
603 * situations where the DBA has gone overboard on creating variant
604 * indexes, this can make for a very large reduction in the number of
605 * paths considered further.)
606 *
607 * We then sort the surviving paths with the cheapest-to-scan first, and
608 * for each path, consider using that path alone as the basis for a bitmap
609 * scan. Then we consider bitmap AND scans formed from that path plus
610 * each subsequent (higher-cost) path, adding on a subsequent path if it
611 * results in a reduction in the estimated total scan cost. This means we
612 * consider about O(N^2) rather than O(2^N) path combinations, which is
613 * quite tolerable, especially given than N is usually reasonably small
614 * because of the prefiltering step. The cheapest of these is returned.
615 *
616 * We will only consider AND combinations in which no two indexes use the
617 * same WHERE clause. This is a bit of a kluge: it's needed because
618 * costsize.c and clausesel.c aren't very smart about redundant clauses.
619 * They will usually double-count the redundant clauses, producing a
620 * too-small selectivity that makes a redundant AND step look like it
621 * reduces the total cost. Perhaps someday that code will be smarter and
622 * we can remove this limitation. (But note that this also defends
623 * against flat-out duplicate input paths, which can happen because
624 * best_inner_indexscan will find the same OR join clauses that
625 * create_or_index_quals has pulled OR restriction clauses out of.)
626 *
627 * For the same reason, we reject AND combinations in which an index
628 * predicate clause duplicates another clause. Here we find it necessary
629 * to be even stricter: we'll reject a partial index if any of its
630 * predicate clauses are implied by the set of WHERE clauses and predicate
631 * clauses used so far. This covers cases such as a condition "x = 42"
632 * used with a plain index, followed by a clauseless scan of a partial
633 * index "WHERE x >= 40 AND x < 50". The partial index has been accepted
634 * only because "x = 42" was present, and so allowing it would partially
635 * double-count selectivity. (We could use predicate_implied_by on
636 * regular qual clauses too, to have a more intelligent, but much more
637 * expensive, check for redundancy --- but in most cases simple equality
638 * seems to suffice.)
639 */
641 /*
642 * Extract clause usage info and detect any paths that use exactly the
643 * same set of clauses; keep only the cheapest-to-scan of any such groups.
644 * The surviving paths are put into an array for qsort'ing.
645 */
651 {
656 {
659 }
661 {
662 /* duplicate clauseids, keep the cheaper one */
663 Cost ncost;
664 Cost ocost;
665 Selectivity nselec;
666 Selectivity oselec;
672 }
673 else
674 {
675 /* not duplicate clauseids, add to array */
677 }
678 }
680 /* If only one surviving path, we're done */
684 /* Sort the surviving paths by index access cost */
686 path_usage_comparator);
688 /*
689 * For each surviving index, consider it as an "AND group leader", and see
690 * whether adding on any of the later indexes results in an AND path with
691 * cheaper total cost than before. Then take the cheapest AND group.
692 */
694 {
695 Cost costsofar;
709 {
710 Cost newcost;
713 /* Check for redundancy */
717 {
720 /* we check each predicate clause separately */
722 {
726 {
729 }
730 }
733 }
734 /* tentatively add new path to paths, so we can estimate cost */
738 {
739 /* keep new path in paths, update subsidiary variables */
748 }
749 else
750 {
751 /* reject new path, remove it from paths list */
753 }
755 }
757 /* Keep the cheapest AND-group (or singleton) */
759 {
762 }
764 /* some easy cleanup (we don't try real hard though) */
766 }
771 }
773 /* qsort comparator to sort in increasing index access cost order */
774 static int
776 {
779 Cost acost;
780 Cost bcost;
781 Selectivity aselec;
782 Selectivity bselec;
787 /*
788 * If costs are the same, sort by selectivity.
789 */
801 }
803 /*
804 * Estimate the cost of actually executing a bitmap scan with a single
805 * index path (no BitmapAnd, at least not at this level).
806 */
807 static Cost
810 {
811 Path bpath;
816 }
818 /*
819 * Estimate the cost of actually executing a BitmapAnd scan with the given
820 * inputs.
821 */
822 static Cost
825 {
826 BitmapAndPath apath;
827 Path bpath;
829 /* Set up a dummy BitmapAndPath */
835 /* Now we can do cost_bitmap_heap_scan */
839 }
842 /*
843 * classify_index_clause_usage
844 * Construct a PathClauseUsage struct describing the WHERE clauses and
845 * index predicate clauses used by the given indexscan path.
846 * We consider two clauses the same if they are equal().
847 *
848 * At some point we might want to migrate this info into the Path data
849 * structure proper, but for the moment it's only needed within
850 * choose_bitmap_and().
851 *
852 * *clauselist is used and expanded as needed to identify all the distinct
853 * clauses seen across successive calls. Caller must initialize it to NIL
854 * before first call of a set.
855 */
858 {
866 /* Recursively find the quals and preds used by the path */
871 /* Build up a bitmapset representing the quals and preds */
874 {
879 }
881 {
886 }
890 }
893 /*
894 * find_indexpath_quals
895 *
896 * Given the Path structure for a plain or bitmap indexscan, extract lists
897 * of all the indexquals and index predicate conditions used in the Path.
898 * These are appended to the initial contents of *quals and *preds (hence
899 * caller should initialize those to NIL).
900 *
901 * This is sort of a simplified version of make_restrictinfo_from_bitmapqual;
902 * here, we are not trying to produce an accurate representation of the AND/OR
903 * semantics of the Path, but just find out all the base conditions used.
904 *
905 * The result lists contain pointers to the expressions used in the Path,
906 * but all the list cells are freshly built, so it's safe to destructively
907 * modify the lists (eg, by concat'ing with other lists).
908 */
909 static void
911 {
913 {
918 {
920 }
921 }
923 {
928 {
930 }
931 }
933 {
938 }
939 else
941 }
944 /*
945 * find_list_position
946 * Return the given node's position (counting from 0) in the given
947 * list of nodes. If it's not equal() to any existing list member,
948 * add it at the end, and return that position.
949 */
950 static int
952 {
958 {
963 i++;
964 }
969 }
972 /****************************************************************************
973 * ---- ROUTINES TO CHECK RESTRICTIONS ----
974 ****************************************************************************/
977 /*
978 * group_clauses_by_indexkey
979 * Find restriction clauses that can be used with an index.
980 *
981 * Returns a list of sublists of RestrictInfo nodes for clauses that can be
982 * used with this index. Each sublist contains clauses that can be used
983 * with one index key (in no particular order); the top list is ordered by
984 * index key. (This is depended on by expand_indexqual_conditions().)
985 *
986 * We can use clauses from either the current clauses or outer_clauses lists,
987 * but *found_clause is set TRUE only if we used at least one clause from
988 * the "current clauses" list. See find_usable_indexes() for motivation.
989 *
990 * outer_relids determines what Vars will be allowed on the other side
991 * of a possible index qual; see match_clause_to_indexcol().
992 *
993 * 'saop_control' indicates whether ScalarArrayOpExpr clauses can be used.
994 * When it's SAOP_REQUIRE, *found_clause is set TRUE only if we used at least
995 * one ScalarArrayOpExpr from the current clauses list.
996 *
997 * If the index has amoptionalkey = false, we give up and return NIL when
998 * there are no restriction clauses matching the first index key. Otherwise,
999 * we return NIL if there are no restriction clauses matching any index key.
1000 * A non-NIL result will have one (possibly empty) sublist for each index key.
1001 *
1002 * Example: given an index on (A,B,C), we would return ((C1 C2) () (C3 C4))
1003 * if we find that clauses C1 and C2 use column A, clauses C3 and C4 use
1004 * column C, and no clauses use column B.
1005 *
1006 * Note: in some circumstances we may find the same RestrictInfos coming
1007 * from multiple places. Defend against redundant outputs by using
1008 * list_append_unique_ptr (pointer equality should be good enough).
1009 */
1010 List *
1013 Relids outer_relids,
1014 SaOpControl saop_control,
1016 {
1027 do
1028 {
1033 /* check the current clauses */
1035 {
1040 indexcol,
1041 curFamily,
1042 rinfo,
1043 outer_relids,
1044 saop_control))
1045 {
1050 }
1051 }
1053 /* check the outer clauses */
1055 {
1060 indexcol,
1061 curFamily,
1062 rinfo,
1063 outer_relids,
1064 saop_control))
1065 {
1068 }
1069 }
1071 /*
1072 * If no clauses match this key, check for amoptionalkey restriction.
1073 */
1079 indexcol++;
1080 families++;
1088 }
1091 /*
1092 * match_clause_to_indexcol()
1093 * Determines whether a restriction clause matches a column of an index.
1094 *
1095 * To match a normal index, the clause:
1096 *
1097 * (1) must be in the form (indexkey op const) or (const op indexkey);
1098 * and
1099 * (2) must contain an operator which is in the same family as the index
1100 * operator for this column, or is a "special" operator as recognized
1101 * by match_special_index_operator().
1102 *
1103 * Our definition of "const" is pretty liberal: we allow Vars belonging
1104 * to the caller-specified outer_relids relations (which had better not
1105 * include the relation whose index is being tested). outer_relids should
1106 * be NULL when checking simple restriction clauses, and the outer side
1107 * of the join when building a join inner scan. Other than that, the
1108 * only thing we don't like is volatile functions.
1109 *
1110 * Note: in most cases we already know that the clause as a whole uses
1111 * vars from the interesting set of relations. The reason for the
1112 * outer_relids test is to reject clauses like (a.f1 OP (b.f2 OP a.f3));
1113 * that's not processable by an indexscan nestloop join on A, whereas
1114 * (a.f1 OP (b.f2 OP c.f3)) is.
1115 *
1116 * Presently, the executor can only deal with indexquals that have the
1117 * indexkey on the left, so we can only use clauses that have the indexkey
1118 * on the right if we can commute the clause to put the key on the left.
1119 * We do not actually do the commuting here, but we check whether a
1120 * suitable commutator operator is available.
1121 *
1122 * It is also possible to match RowCompareExpr clauses to indexes (but
1123 * currently, only btree indexes handle this). In this routine we will
1124 * report a match if the first column of the row comparison matches the
1125 * target index column. This is sufficient to guarantee that some index
1126 * condition can be constructed from the RowCompareExpr --- whether the
1127 * remaining columns match the index too is considered in
1128 * expand_indexqual_rowcompare().
1129 *
1130 * It is also possible to match ScalarArrayOpExpr clauses to indexes, when
1131 * the clause is of the form "indexkey op ANY (arrayconst)". Since the
1132 * executor can only handle these in the context of bitmap index scans,
1133 * our caller specifies whether to allow these or not.
1134 *
1135 * For boolean indexes, it is also possible to match the clause directly
1136 * to the indexkey; or perhaps the clause is (NOT indexkey).
1137 *
1138 * 'index' is the index of interest.
1139 * 'indexcol' is a column number of 'index' (counting from 0).
1140 * 'opfamily' is the corresponding operator family.
1141 * 'rinfo' is the clause to be tested (as a RestrictInfo node).
1142 * 'saop_control' indicates whether ScalarArrayOpExpr clauses can be used.
1143 *
1144 * Returns true if the clause can be used with this index key.
1145 *
1146 * NOTE: returns false if clause is an OR or AND clause; it is the
1147 * responsibility of higher-level routines to cope with those.
1148 */
1149 static bool
1152 Oid opfamily,
1154 Relids outer_relids,
1155 SaOpControl saop_control)
1156 {
1160 Relids left_relids;
1161 Relids right_relids;
1162 Oid expr_op;
1165 /*
1166 * Never match pseudoconstants to indexes. (Normally this could not
1167 * happen anyway, since a pseudoconstant clause couldn't contain a Var,
1168 * but what if someone builds an expression index on a constant? It's not
1169 * totally unreasonable to do so with a partial index, either.)
1170 */
1174 /* First check for boolean-index cases. */
1176 {
1179 }
1181 /*
1182 * Clause must be a binary opclause, or possibly a ScalarArrayOpExpr
1183 * (which is always binary, by definition). Or it could be a
1184 * RowCompareExpr, which we pass off to match_rowcompare_to_indexcol().
1185 * Or, if the index supports it, we can handle IS NULL clauses.
1186 */
1188 {
1197 }
1200 {
1203 /* We only accept ANY clauses, not ALL */
1212 }
1214 {
1217 outer_relids);
1218 }
1220 {
1227 }
1228 else
1231 /*
1232 * Check for clauses of the form: (indexkey operator constant) or
1233 * (constant operator indexkey). See above notes about const-ness.
1234 */
1238 {
1242 /*
1243 * If we didn't find a member of the index's opfamily, see whether it
1244 * is a "special" indexable operator.
1245 */
1250 }
1256 {
1260 /*
1261 * If we didn't find a member of the index's opfamily, see whether it
1262 * is a "special" indexable operator.
1263 */
1267 }
1270 }
1272 /*
1273 * is_indexable_operator
1274 * Does the operator match the specified index opfamily?
1275 *
1276 * If the indexkey is on the right, what we actually want to know
1277 * is whether the operator has a commutator operator that matches
1278 * the opfamily.
1279 */
1280 static bool
1282 {
1283 /* Get the commuted operator if necessary */
1285 {
1289 }
1291 /* OK if the (commuted) operator is a member of the index's opfamily */
1293 }
1295 /*
1296 * match_rowcompare_to_indexcol()
1297 * Handles the RowCompareExpr case for match_clause_to_indexcol(),
1298 * which see for comments.
1299 */
1300 static bool
1303 Oid opfamily,
1305 Relids outer_relids)
1306 {
1309 Oid expr_op;
1311 /* Forget it if we're not dealing with a btree index */
1315 /*
1316 * We could do the matching on the basis of insisting that the opfamily
1317 * shown in the RowCompareExpr be the same as the index column's opfamily,
1318 * but that could fail in the presence of reverse-sort opfamilies: it'd be
1319 * a matter of chance whether RowCompareExpr had picked the forward or
1320 * reverse-sort family. So look only at the operator, and match if it is
1321 * a member of the index's opfamily (after commutation, if the indexkey is
1322 * on the right). We'll worry later about whether any additional
1323 * operators are matchable to the index.
1324 */
1329 /*
1330 * These syntactic tests are the same as in match_clause_to_indexcol()
1331 */
1335 {
1336 /* OK, indexkey is on left */
1337 }
1341 {
1342 /* indexkey is on right, so commute the operator */
1346 }
1347 else
1350 /* We're good if the operator is the right type of opfamily member */
1352 {
1358 }
1361 }
1364 /****************************************************************************
1365 * ---- ROUTINES TO DO PARTIAL INDEX PREDICATE TESTS ----
1366 ****************************************************************************/
1368 /*
1369 * check_partial_indexes
1370 * Check each partial index of the relation, and mark it predOK or not
1371 * depending on whether the predicate is satisfied for this query.
1372 */
1373 void
1375 {
1380 {
1387 restrictinfo_list);
1388 }
1389 }
1391 /****************************************************************************
1392 * ---- ROUTINES TO CHECK JOIN CLAUSES ----
1393 ****************************************************************************/
1395 /*
1396 * indexable_outerrelids
1397 * Finds all other relids that participate in any indexable join clause
1398 * for the specified table. Returns a set of relids.
1399 */
1400 static Relids
1402 {
1407 /*
1408 * Examine each joinclause in the joininfo list to see if it matches any
1409 * key of any index. If so, add the clause's other rels to the result.
1410 */
1412 {
1414 Relids other_rels;
1419 else
1421 }
1423 /*
1424 * We also have to look through the query's EquivalenceClasses to see if
1425 * any of them could generate indexable join conditions for this rel.
1426 */
1428 {
1430 {
1436 /*
1437 * Won't generate joinclauses if const or single-member (the
1438 * latter test covers the volatile case too)
1439 */
1443 /*
1444 * Note we don't test ec_broken; if we did, we'd need a separate
1445 * code path to look through ec_sources. Checking the members
1446 * anyway is OK as a possibly-overoptimistic heuristic.
1447 */
1449 /*
1450 * No point in searching if rel not mentioned in eclass (but we
1451 * can't tell that for a child rel).
1452 */
1457 /*
1458 * Scan members, looking for both an index match and join
1459 * candidates
1460 */
1462 {
1465 /* Join candidate? */
1468 {
1472 }
1474 /* Check for index match (only need one) */
1479 }
1483 else
1485 }
1486 }
1489 }
1491 /*
1492 * matches_any_index
1493 * Workhorse for indexable_outerrelids: see if a joinclause can be
1494 * matched to any index of the given rel.
1495 */
1496 static bool
1498 {
1504 {
1506 {
1509 /* OR arguments should be ANDs or sub-RestrictInfos */
1511 {
1514 /* Recurse to examine AND items and sub-ORs */
1516 {
1521 }
1522 }
1523 else
1524 {
1525 /* Recurse to examine simple clause */
1529 outer_relids))
1531 }
1532 }
1535 }
1537 /* Normal case for a simple restriction clause */
1539 {
1544 do
1545 {
1549 indexcol,
1550 curFamily,
1551 rinfo,
1552 outer_relids,
1553 SAOP_ALLOW))
1556 indexcol++;
1557 families++;
1559 }
1562 }
1564 /*
1565 * eclass_matches_any_index
1566 * Workhorse for indexable_outerrelids: see if an EquivalenceClass member
1567 * can be matched to any index column of the given rel.
1568 *
1569 * This is also exported for use by find_eclass_clauses_for_index_join.
1570 */
1571 bool
1574 {
1578 {
1583 do
1584 {
1587 /*
1588 * If it's a btree index, we can reject it if its opfamily isn't
1589 * compatible with the EC, since no clause generated from the
1590 * EC could be used with the index. For non-btree indexes,
1591 * we can't easily tell whether clauses generated from the EC
1592 * could be used with the index, so only check for expression
1593 * match. This might mean we return "true" for a useless index,
1594 * but that will just cause some wasted planner cycles; it's
1595 * better than ignoring useful indexes.
1596 */
1602 indexcol++;
1603 families++;
1605 }
1608 }
1611 /*
1612 * best_inner_indexscan
1613 * Finds the best available inner indexscans for a nestloop join
1614 * with the given rel on the inside and the given outer_rel outside.
1615 *
1616 * *cheapest_startup gets the path with least startup cost
1617 * *cheapest_total gets the path with least total cost (often the same path)
1618 * Both are set to NULL if there are no possible inner indexscans.
1619 *
1620 * We ignore ordering considerations, since a nestloop's inner scan's order
1621 * is uninteresting. Hence startup cost and total cost are the only figures
1622 * of merit to consider.
1623 *
1624 * Note: create_index_paths() must have been run previously for this rel,
1625 * else the results will always be NULL.
1626 */
1627 void
1631 {
1632 Relids outer_relids;
1639 MemoryContext oldcontext;
1641 /* Initialize results for failure returns */
1644 /*
1645 * Nestloop only supports inner, left, semi, and anti joins.
1646 */
1648 {
1659 }
1661 /*
1662 * If there are no indexable joinclauses for this rel, exit quickly.
1663 */
1667 /*
1668 * Otherwise, we have to do path selection in the main planning context,
1669 * so that any created path can be safely attached to the rel's cache of
1670 * best inner paths. (This is not currently an issue for normal planning,
1671 * but it is an issue for GEQO planning.)
1672 */
1675 /*
1676 * Intersect the given outer relids with index_outer_relids to find the
1677 * set of outer relids actually relevant for this rel. If there are none,
1678 * again we can fail immediately.
1679 */
1682 {
1686 }
1688 /*
1689 * Look to see if we already computed the result for this set of relevant
1690 * outerrels. (We include the isouterjoin status in the cache lookup key
1691 * for safety. In practice I suspect this is not necessary because it
1692 * should always be the same for a given combination of rels.)
1693 *
1694 * NOTE: because we cache on outer_relids rather than outer_rel->relids,
1695 * we will report the same paths and hence path cost for joins with
1696 * different sets of irrelevant rels on the outside. Now that cost_index
1697 * is sensitive to outer_rel->rows, this is not really right. However the
1698 * error is probably not large. Is it worth establishing a separate cache
1699 * entry for each distinct outer_rel->relids set to get this right?
1700 */
1702 {
1706 {
1712 }
1713 }
1715 /*
1716 * Find all the relevant restriction and join clauses.
1717 *
1718 * Note: because we include restriction clauses, we will find indexscans
1719 * that could be plain indexscans, ie, they don't require the join context
1720 * at all. This may seem redundant, but we need to include those scans in
1721 * the input given to choose_bitmap_and() to be sure we find optimal AND
1722 * combinations of join and non-join scans. Also, even if the "best inner
1723 * indexscan" is just a plain indexscan, it will have a different cost
1724 * estimate because of cache effects.
1725 */
1728 /*
1729 * Find all the index paths that are usable for this join, except for
1730 * stuff involving OR and ScalarArrayOpExpr clauses.
1731 */
1735 SAOP_FORBID);
1737 /*
1738 * Generate BitmapOrPaths for any suitable OR-clauses present in the
1739 * clause list.
1740 */
1743 outer_rel);
1745 /*
1746 * Likewise, generate paths using ScalarArrayOpExpr clauses; these can't
1747 * be simple indexscans but they can be used in bitmap scans.
1748 */
1754 /*
1755 * Include the regular index paths in bitindexpaths.
1756 */
1759 /*
1760 * If we found anything usable, generate a BitmapHeapPath for the most
1761 * promising combination of bitmap index paths.
1762 */
1764 {
1771 }
1773 /*
1774 * Now choose the cheapest members of indexpaths.
1775 */
1777 {
1781 {
1788 }
1789 }
1791 /* Cache the results --- whether positive or negative */
1800 }
1802 /*
1803 * find_clauses_for_join
1804 * Generate a list of clauses that are potentially useful for
1805 * scanning rel as the inner side of a nestloop join.
1806 *
1807 * We consider both join and restriction clauses. Any joinclause that uses
1808 * only otherrels in the specified outer_relids is fair game. But there must
1809 * be at least one such joinclause in the final list, otherwise we return NIL
1810 * indicating that there isn't any potential win here.
1811 */
1815 {
1817 Relids join_relids;
1820 /*
1821 * Look for joinclauses that are usable with given outer_relids. Note
1822 * we'll take anything that's applicable to the join whether it has
1823 * anything to do with an index or not; since we're only building a list,
1824 * it's not worth filtering more finely here.
1825 */
1829 {
1832 /* Can't use pushed-down join clauses in outer join */
1839 }
1843 /*
1844 * Also check to see if any EquivalenceClasses can produce a relevant
1845 * joinclause. Since all such clauses are effectively pushed-down, this
1846 * doesn't apply to outer joins.
1847 */
1851 rel,
1852 outer_relids));
1854 /* If no join clause was matched then forget it, per comments above */
1858 /* We can also use any plain restriction clauses for the rel */
1862 }
1865 /****************************************************************************
1866 * ---- PATH CREATION UTILITIES ----
1867 ****************************************************************************/
1869 /*
1870 * flatten_clausegroups_list
1871 * Given a list of lists of RestrictInfos, flatten it to a list
1872 * of RestrictInfos.
1873 *
1874 * This is used to flatten out the result of group_clauses_by_indexkey()
1875 * to produce an indexclauses list. The original list structure mustn't
1876 * be altered, but it's OK to share copies of the underlying RestrictInfos.
1877 */
1878 List *
1880 {
1887 }
1890 /****************************************************************************
1891 * ---- ROUTINES TO CHECK OPERANDS ----
1892 ****************************************************************************/
1894 /*
1895 * match_index_to_operand()
1896 * Generalized test for a match between an index's key
1897 * and the operand on one side of a restriction or join clause.
1898 *
1899 * operand: the nodetree to be compared to the index
1900 * indexcol: the column number of the index (counting from 0)
1901 * index: the index of interest
1902 */
1903 bool
1907 {
1910 /*
1911 * Ignore any RelabelType node above the operand. This is needed to be
1912 * able to apply indexscanning in binary-compatible-operator cases. Note:
1913 * we can assume there is at most one RelabelType node;
1914 * eval_const_expressions() will have simplified if more than one.
1915 */
1921 {
1922 /*
1923 * Simple index column; operand must be a matching Var.
1924 */
1929 }
1930 else
1931 {
1932 /*
1933 * Index expression; find the correct expression. (This search could
1934 * be avoided, at the cost of complicating all the callers of this
1935 * routine; doesn't seem worth it.)
1936 */
1943 {
1945 {
1949 }
1950 }
1955 /*
1956 * Does it match the operand? Again, strip any relabeling.
1957 */
1963 }
1966 }
1968 /****************************************************************************
1969 * ---- ROUTINES FOR "SPECIAL" INDEXABLE OPERATORS ----
1970 ****************************************************************************/
1972 /*----------
1973 * These routines handle special optimization of operators that can be
1974 * used with index scans even though they are not known to the executor's
1975 * indexscan machinery. The key idea is that these operators allow us
1976 * to derive approximate indexscan qual clauses, such that any tuples
1977 * that pass the operator clause itself must also satisfy the simpler
1978 * indexscan condition(s). Then we can use the indexscan machinery
1979 * to avoid scanning as much of the table as we'd otherwise have to,
1980 * while applying the original operator as a qpqual condition to ensure
1981 * we deliver only the tuples we want. (In essence, we're using a regular
1982 * index as if it were a lossy index.)
1983 *
1984 * An example of what we're doing is
1985 * textfield LIKE 'abc%'
1986 * from which we can generate the indexscanable conditions
1987 * textfield >= 'abc' AND textfield < 'abd'
1988 * which allow efficient scanning of an index on textfield.
1989 * (In reality, character set and collation issues make the transformation
1990 * from LIKE to indexscan limits rather harder than one might think ...
1991 * but that's the basic idea.)
1992 *
1993 * Another thing that we do with this machinery is to provide special
1994 * smarts for "boolean" indexes (that is, indexes on boolean columns
1995 * that support boolean equality). We can transform a plain reference
1996 * to the indexkey into "indexkey = true", or "NOT indexkey" into
1997 * "indexkey = false", so as to make the expression indexable using the
1998 * regular index operators. (As of Postgres 8.1, we must do this here
1999 * because constant simplification does the reverse transformation;
2000 * without this code there'd be no way to use such an index at all.)
2001 *
2002 * Three routines are provided here:
2003 *
2004 * match_special_index_operator() is just an auxiliary function for
2005 * match_clause_to_indexcol(); after the latter fails to recognize a
2006 * restriction opclause's operator as a member of an index's opfamily,
2007 * it asks match_special_index_operator() whether the clause should be
2008 * considered an indexqual anyway.
2009 *
2010 * match_boolean_index_clause() similarly detects clauses that can be
2011 * converted into boolean equality operators.
2012 *
2013 * expand_indexqual_conditions() converts a list of lists of RestrictInfo
2014 * nodes (with implicit AND semantics across list elements) into
2015 * a list of clauses that the executor can actually handle. For operators
2016 * that are members of the index's opfamily this transformation is a no-op,
2017 * but clauses recognized by match_special_index_operator() or
2018 * match_boolean_index_clause() must be converted into one or more "regular"
2019 * indexqual conditions.
2020 *----------
2021 */
2023 /*
2024 * match_boolean_index_clause
2025 * Recognize restriction clauses that can be matched to a boolean index.
2026 *
2027 * This should be called only when IsBooleanOpfamily() recognizes the
2028 * index's operator family. We check to see if the clause matches the
2029 * index's key.
2030 */
2031 static bool
2035 {
2036 /* Direct match? */
2039 /* NOT clause? */
2041 {
2045 }
2047 /*
2048 * Since we only consider clauses at top level of WHERE, we can convert
2049 * indexkey IS TRUE and indexkey IS FALSE to index searches as well. The
2050 * different meaning for NULL isn't important.
2051 */
2053 {
2061 }
2063 }
2065 /*
2066 * match_special_index_operator
2067 * Recognize restriction clauses that can be used to generate
2068 * additional indexscanable qualifications.
2069 *
2070 * The given clause is already known to be a binary opclause having
2071 * the form (indexkey OP pseudoconst) or (pseudoconst OP indexkey),
2072 * but the OP proved not to be one of the index's opfamily operators.
2073 * Return 'true' if we can do something with it anyway.
2074 */
2075 static bool
2078 {
2081 Oid expr_op;
2086 /*
2087 * Currently, all known special operators require the indexkey on the
2088 * left, but this test could be pushed into the switch statement if some
2089 * are added that do not...
2090 */
2094 /* we know these will succeed */
2098 /* again, required for all current special ops: */
2105 {
2109 /* the right-hand const is type text for all of these */
2122 /* the right-hand const is type text for all of these */
2130 /* the right-hand const is type text for all of these */
2138 /* the right-hand const is type text for all of these */
2147 }
2150 {
2153 }
2155 /* done if the expression doesn't look indexable */
2159 /*
2160 * Must also check that index's opfamily supports the operators we will
2161 * want to apply. (A hash index, for example, will not support ">=".)
2162 * Currently, only btree supports the operators we need.
2163 *
2164 * We insist on the opfamily being the specific one we expect, else we'd
2165 * do the wrong thing if someone were to make a reverse-sort opfamily with
2166 * the same operators.
2167 */
2169 {
2174 isIndexable =
2183 isIndexable =
2192 /* name uses locale-insensitive sorting */
2204 }
2207 }
2209 /*
2210 * expand_indexqual_conditions
2211 * Given a list of sublists of RestrictInfo nodes, produce a flat list
2212 * of index qual clauses. Standard qual clauses (those in the index's
2213 * opfamily) are passed through unchanged. Boolean clauses and "special"
2214 * index operators are expanded into clauses that the indexscan machinery
2215 * will know what to do with. RowCompare clauses are simplified if
2216 * necessary to create a clause that is fully checkable by the index.
2217 *
2218 * The input list is ordered by index key, and so the output list is too.
2219 * (The latter is not depended on by any part of the core planner, I believe,
2220 * but parts of the executor require it, and so do the amcostestimate
2221 * functions.)
2222 */
2223 List *
2225 {
2235 do
2236 {
2241 {
2245 /* First check for boolean cases */
2247 {
2251 indexcol,
2252 index);
2254 {
2260 NULL));
2262 }
2263 }
2265 /*
2266 * Else it must be an opclause (usual case), ScalarArrayOp,
2267 * RowCompare, or NullTest
2268 */
2270 {
2273 curFamily));
2274 }
2276 {
2277 /* no extra work at this time */
2279 }
2281 {
2284 index,
2285 indexcol));
2286 }
2288 {
2295 NULL));
2296 }
2297 else
2300 }
2304 indexcol++;
2305 families++;
2311 }
2313 /*
2314 * expand_boolean_index_clause
2315 * Convert a clause recognized by match_boolean_index_clause into
2316 * a boolean equality operator clause.
2317 *
2318 * Returns NULL if the clause isn't a boolean index qual.
2319 */
2324 {
2325 /* Direct match? */
2327 {
2328 /* convert to indexkey = TRUE */
2332 }
2333 /* NOT clause? */
2335 {
2338 /* It must have matched the indexkey */
2340 /* convert to indexkey = FALSE */
2344 }
2346 {
2350 /* It must have matched the indexkey */
2353 {
2354 /* convert to indexkey = TRUE */
2358 }
2360 {
2361 /* convert to indexkey = FALSE */
2365 }
2366 /* Oops */
2368 }
2371 }
2373 /*
2374 * expand_indexqual_opclause --- expand a single indexqual condition
2375 * that is an operator clause
2376 *
2377 * The input is a single RestrictInfo, the output a list of RestrictInfos.
2378 *
2379 * In the base case this is just list_make1(), but we have to be prepared to
2380 * expand special cases that were accepted by match_special_index_operator().
2381 */
2384 {
2387 /* we know these will succeed */
2394 Pattern_Prefix_Status pstatus;
2396 /*
2397 * LIKE and regex operators are not members of any btree index opfamily,
2398 * but they can be members of opfamilies for more exotic index types such
2399 * as GIN. Therefore, we should only do expansion if the operator is
2400 * actually not in the opfamily. But checking that requires a syscache
2401 * lookup, so it's best to first see if the operator is one we are
2402 * interested in.
2403 */
2405 {
2411 {
2415 }
2422 {
2423 /* the right-hand const is type text for all of these */
2427 }
2434 {
2435 /* the right-hand const is type text for all of these */
2439 }
2446 {
2447 /* the right-hand const is type text for all of these */
2451 }
2457 {
2460 }
2462 }
2464 /* Default case: just make a list of the unmodified indexqual */
2466 }
2468 /*
2469 * expand_indexqual_rowcompare --- expand a single indexqual condition
2470 * that is a RowCompareExpr
2471 *
2472 * It's already known that the first column of the row comparison matches
2473 * the specified column of the index. We can use additional columns of the
2474 * row comparison as index qualifications, so long as they match the index
2475 * in the "same direction", ie, the indexkeys are all on the same side of the
2476 * clause and the operators are all the same-type members of the opfamilies.
2477 * If all the columns of the RowCompareExpr match in this way, we just use it
2478 * as-is. Otherwise, we build a shortened RowCompareExpr (if more than one
2479 * column matches) or a simple OpExpr (if the first-column match is all
2480 * there is). In these cases the modified clause is always "<=" or ">="
2481 * even when the original was "<" or ">" --- this is necessary to match all
2482 * the rows that could match the original. (We are essentially building a
2483 * lossy version of the row comparison when we do this.)
2484 */
2489 {
2493 Oid op_lefttype;
2494 Oid op_righttype;
2496 Oid expr_op;
2505 /* We have to figure out (again) how the first col matches */
2518 /* Build lists of the opfamilies and operator datatypes in case needed */
2523 /*
2524 * See how many of the remaining columns match some index column in the
2525 * same way. A note about rel membership tests: we assume that the clause
2526 * as a whole is already known to use only Vars from the indexed relation
2527 * and possibly some acceptable outer relations. So the "other" side of
2528 * any potential index condition is OK as long as it doesn't use Vars from
2529 * the indexed relation.
2530 */
2537 {
2544 {
2547 }
2548 else
2549 {
2552 /* indexkey is on right, so commute the operator */
2556 }
2562 /*
2563 * The Var side can match any column of the index. If the user does
2564 * something weird like having multiple identical index columns, we
2565 * insist the match be on the first such column, to avoid confusing
2566 * the executor.
2567 */
2569 {
2572 }
2576 /* Now, do we have the right operator for this column? */
2581 /* Add opfamily and datatypes to lists */
2590 /* This column matches, keep scanning */
2591 matching_cols++;
2595 }
2597 /* Return clause as-is if it's all usable as index quals */
2601 /*
2602 * We have to generate a subset rowcompare (possibly just one OpExpr). The
2603 * painful part of this is changing < to <= or > to >=, so deal with that
2604 * first.
2605 */
2608 {
2609 /* easy, just use the same operators */
2611 }
2612 else
2613 {
2622 else
2628 {
2634 op_strategy);
2639 {
2644 }
2648 }
2649 }
2651 /* If we have more than one matching col, create a subset rowcompare */
2653 {
2658 else
2663 matching_cols);
2665 matching_cols);
2667 matching_cols);
2669 }
2670 else
2671 {
2678 }
2679 }
2681 /*
2682 * Given a fixed prefix that all the "leftop" values must have,
2683 * generate suitable indexqual condition(s). opfamily is the index
2684 * operator family; we use it to deduce the appropriate comparison
2685 * operators and operand datatypes.
2686 */
2690 {
2692 Oid datatype;
2693 Oid oproid;
2695 FmgrInfo ltproc;
2701 {
2721 /* shouldn't get here */
2724 }
2726 /*
2727 * If necessary, coerce the prefix constant to the right type. The given
2728 * prefix constant is either text or bytea type.
2729 */
2731 {
2735 {
2747 }
2750 }
2752 /*
2753 * If we found an exact-match pattern, generate an "=" indexqual.
2754 */
2756 {
2758 BTEqualStrategyNumber);
2765 }
2767 /*
2768 * Otherwise, we have a nonempty required prefix of the values.
2769 *
2770 * We can always say "x >= prefix".
2771 */
2773 BTGreaterEqualStrategyNumber);
2780 /*-------
2781 * If we can create a string larger than the prefix, we can say
2782 * "x < greaterstr".
2783 *-------
2784 */
2786 BTLessStrategyNumber);
2792 {
2797 }
2800 }
2802 /*
2803 * Given a leftop and a rightop, and a inet-family sup/sub operator,
2804 * generate suitable indexqual condition(s). expr_op is the original
2805 * operator, and opfamily is the index opfamily.
2806 */
2809 {
2811 Oid datatype;
2812 Oid opr1oid;
2813 Oid opr2oid;
2814 Datum opr1right;
2815 Datum opr2right;
2820 {
2832 }
2834 /*
2835 * create clause "key >= network_scan_first( rightop )", or ">" if the
2836 * operator disallows equality.
2837 */
2839 {
2841 BTGreaterEqualStrategyNumber);
2844 }
2845 else
2846 {
2848 BTGreaterStrategyNumber);
2851 }
2861 /* create clause "key <= network_scan_last( rightop )" */
2864 BTLessEqualStrategyNumber);
2878 }
2880 /*
2881 * Handy subroutines for match_special_index_operator() and friends.
2882 */
2884 /*
2885 * Generate a Datum of the appropriate type from a C string.
2886 * Note that all of the supported types are pass-by-ref, so the
2887 * returned value should be pfree'd if no longer needed.
2888 */
2889 static Datum
2891 {
2892 /*
2893 * We cheat a little by assuming that CStringGetTextDatum() will do for
2894 * bpchar and varchar constants too...
2895 */
2900 else
2902 }
2904 /*
2905 * Generate a Const node of the appropriate type from a C string.
2906 */
2909 {
2915 }