| blob | cc36cad2355eb112c46372c79842ffd64b86cc78 |
1 /*-------------------------------------------------------------------------
2 *
3 * equivclass.c
4 * Routines for managing EquivalenceClasses
5 *
6 * See src/backend/optimizer/README for discussion of EquivalenceClasses.
7 *
8 *
9 * Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
10 * Portions Copyright (c) 1994, Regents of the University of California
11 *
12 * IDENTIFICATION
13 * $PostgreSQL$
14 *
15 *-------------------------------------------------------------------------
16 */
63 /*
64 * process_equivalence
65 * The given clause has a mergejoinable operator and can be applied without
66 * any delay by an outer join, so its two sides can be considered equal
67 * anywhere they are both computable; moreover that equality can be
68 * extended transitively. Record this knowledge in the EquivalenceClass
69 * data structure. Returns TRUE if successful, FALSE if not (in which
70 * case caller should treat the clause as ordinary, not an equivalence).
71 *
72 * If below_outer_join is true, then the clause was found below the nullable
73 * side of an outer join, so its sides might validly be both NULL rather than
74 * strictly equal. We can still deduce equalities in such cases, but we take
75 * care to mark an EquivalenceClass if it came from any such clauses. Also,
76 * we have to check that both sides are either pseudo-constants or strict
77 * functions of Vars, else they might not both go to NULL above the outer
78 * join. (This is the reason why we need a failure return. It's more
79 * convenient to check this case here than at the call sites...)
80 *
81 * Note: constructing merged EquivalenceClasses is a standard UNION-FIND
82 * problem, for which there exist better data structures than simple lists.
83 * If this code ever proves to be a bottleneck then it could be sped up ---
84 * but for now, simple is beautiful.
85 *
86 * Note: this is only called during planner startup, not during GEQO
87 * exploration, so we need not worry about whether we're in the right
88 * memory context.
89 */
90 bool
93 {
95 Oid opno,
96 item1_type,
97 item2_type;
100 Relids item1_relids,
101 item2_relids;
109 /* Extract info from given clause */
117 /*
118 * If below outer join, check for strictness, else reject.
119 */
121 {
128 }
130 /*
131 * We use the declared input types of the operator, not exprType() of the
132 * inputs, as the nominal datatypes for opfamily lookup. This presumes
133 * that btree operators are always registered with amoplefttype and
134 * amoprighttype equal to their declared input types. We will need this
135 * info anyway to build EquivalenceMember nodes, and by extracting it now
136 * we can use type comparisons to short-circuit some equal() tests.
137 */
142 /*
143 * Sweep through the existing EquivalenceClasses looking for matches to
144 * item1 and item2. These are the possible outcomes:
145 *
146 * 1. We find both in the same EC. The equivalence is already known, so
147 * there's nothing to do.
148 *
149 * 2. We find both in different ECs. Merge the two ECs together.
150 *
151 * 3. We find just one. Add the other to its EC.
152 *
153 * 4. We find neither. Make a new, two-entry EC.
154 *
155 * Note: since all ECs are built through this process, it's impossible
156 * that we'd match an item in more than one existing EC. It is possible
157 * to match more than once within an EC, if someone fed us something silly
158 * like "WHERE X=X". (However, we can't simply discard such clauses,
159 * since they should fail when X is null; so we will build a 2-member EC
160 * to ensure the correct restriction clause gets generated. Hence there
161 * is no shortcut here for item1 and item2 equal.)
162 */
166 {
170 /* Never match to a volatile EC */
174 /*
175 * A "match" requires matching sets of btree opfamilies. Use of
176 * equal() for this test has implications discussed in the comments
177 * for get_mergejoin_opfamilies().
178 */
183 {
188 /*
189 * If below an outer join, don't match constants: they're not as
190 * constant as they look.
191 */
199 {
204 }
209 {
214 }
215 }
219 }
221 /* Sweep finished, what did we find? */
224 {
225 /* If case 1, nothing to do, except add to sources */
227 {
230 /* mark the RI as usable with this pair of EMs */
231 /* NB: can't set left_ec/right_ec until merging is finished */
235 }
237 /*
238 * Case 2: need to merge ec1 and ec2. We add ec2's items to ec1, then
239 * set ec2's ec_merged link to point to ec1 and remove ec2 from the
240 * eq_classes list. We cannot simply delete ec2 because that could
241 * leave dangling pointers in existing PathKeys. We leave it behind
242 * with a link so that the merged EC can be found.
243 */
249 /* can't need to set has_volatile */
253 /* just to avoid debugging confusion w/ dangling pointers: */
260 /* mark the RI as usable with this pair of EMs */
263 }
265 {
266 /* Case 3: add item2 to ec1 */
270 /* mark the RI as usable with this pair of EMs */
273 }
275 {
276 /* Case 3: add item1 to ec2 */
280 /* mark the RI as usable with this pair of EMs */
283 }
284 else
285 {
286 /* Case 4: make a new, two-entry EC */
305 /* mark the RI as usable with this pair of EMs */
308 }
311 }
313 /*
314 * add_eq_member - build a new EquivalenceMember and add it to an EC
315 */
319 {
329 {
330 /*
331 * No Vars, assume it's a pseudoconstant. This is correct for entries
332 * generated from process_equivalence(), because a WHERE clause can't
333 * contain aggregates or SRFs, and non-volatility was checked before
334 * process_equivalence() ever got called. But
335 * get_eclass_for_sort_expr() has to work harder. We put the tests
336 * there not here to save cycles in the equivalence case.
337 */
341 /* it can't affect ec_relids */
342 }
344 {
346 }
350 }
353 /*
354 * get_eclass_for_sort_expr
355 * Given an expression and opfamily info, find an existing equivalence
356 * class it is a member of; if none, build a new single-member
357 * EquivalenceClass for it.
358 *
359 * sortref is the SortGroupRef of the originating SortGroupClause, if any,
360 * or zero if not.
361 *
362 * This can be used safely both before and after EquivalenceClass merging;
363 * since it never causes merging it does not invalidate any existing ECs
364 * or PathKeys.
365 *
366 * Note: opfamilies must be chosen consistently with the way
367 * process_equivalence() would do; that is, generated from a mergejoinable
368 * equality operator. Else we might fail to detect valid equivalences,
369 * generating poor (but not incorrect) plans.
370 */
371 EquivalenceClass *
374 Oid expr_datatype,
376 Index sortref)
377 {
381 MemoryContext oldcontext;
383 /*
384 * Scan through the existing EquivalenceClasses for a match
385 */
387 {
391 /* Never match to a volatile EC */
399 {
402 /*
403 * If below an outer join, don't match constants: they're not as
404 * constant as they look.
405 */
413 }
414 }
416 /*
417 * No match, so build a new single-member EC
418 *
419 * Here, we must be sure that we construct the EC in the right context. We
420 * can assume, however, that the passed expr is long-lived.
421 */
439 /*
440 * add_eq_member doesn't check for volatile functions, set-returning
441 * functions, aggregates, or window functions, but such could appear in
442 * sort expressions; so we have to check whether its const-marking was
443 * correct.
444 */
446 {
451 {
454 }
455 }
462 }
465 /*
466 * generate_base_implied_equalities
467 * Generate any restriction clauses that we can deduce from equivalence
468 * classes.
469 *
470 * When an EC contains pseudoconstants, our strategy is to generate
471 * "member = const1" clauses where const1 is the first constant member, for
472 * every other member (including other constants). If we are able to do this
473 * then we don't need any "var = var" comparisons because we've successfully
474 * constrained all the vars at their points of creation. If we fail to
475 * generate any of these clauses due to lack of cross-type operators, we fall
476 * back to the "ec_broken" strategy described below. (XXX if there are
477 * multiple constants of different types, it's possible that we might succeed
478 * in forming all the required clauses if we started from a different const
479 * member; but this seems a sufficiently hokey corner case to not be worth
480 * spending lots of cycles on.)
481 *
482 * For ECs that contain no pseudoconstants, we generate derived clauses
483 * "member1 = member2" for each pair of members belonging to the same base
484 * relation (actually, if there are more than two for the same base relation,
485 * we only need enough clauses to link each to each other). This provides
486 * the base case for the recursion: each row emitted by a base relation scan
487 * will constrain all computable members of the EC to be equal. As each
488 * join path is formed, we'll add additional derived clauses on-the-fly
489 * to maintain this invariant (see generate_join_implied_equalities).
490 *
491 * If the opfamilies used by the EC do not provide complete sets of cross-type
492 * equality operators, it is possible that we will fail to generate a clause
493 * that must be generated to maintain the invariant. (An example: given
494 * "WHERE a.x = b.y AND b.y = a.z", the scheme breaks down if we cannot
495 * generate "a.x = a.z" as a restriction clause for A.) In this case we mark
496 * the EC "ec_broken" and fall back to regurgitating its original source
497 * RestrictInfos at appropriate times. We do not try to retract any derived
498 * clauses already generated from the broken EC, so the resulting plan could
499 * be poor due to bad selectivity estimates caused by redundant clauses. But
500 * the correct solution to that is to fix the opfamilies ...
501 *
502 * Equality clauses derived by this function are passed off to
503 * process_implied_equality (in plan/initsplan.c) to be inserted into the
504 * restrictinfo datastructures. Note that this must be called after initial
505 * scanning of the quals and before Path construction begins.
506 *
507 * We make no attempt to avoid generating duplicate RestrictInfos here: we
508 * don't search ec_sources for matches, nor put the created RestrictInfos
509 * into ec_derives. Doing so would require some slightly ugly changes in
510 * initsplan.c's API, and there's no real advantage, because the clauses
511 * generated here can't duplicate anything we will generate for joins anyway.
512 */
513 void
515 {
517 Index rti;
520 {
526 /* Single-member ECs won't generate any deductions */
532 else
535 /* Recover if we failed to generate required derived clauses */
538 }
540 /*
541 * This is also a handy place to mark base rels (which should all exist by
542 * now) with flags showing whether they have pending eclass joins.
543 */
545 {
552 }
553 }
555 /*
556 * generate_base_implied_equalities when EC contains pseudoconstant(s)
557 */
558 static void
561 {
565 /*
566 * In the trivial case where we just had one "var = const" clause, push
567 * the original clause back into the main planner machinery. There is
568 * nothing to be gained by doing it differently, and we save the effort to
569 * re-build and re-analyze an equality clause that will be exactly
570 * equivalent to the old one.
571 */
574 {
578 {
581 }
582 }
584 /* Find the constant member to use */
586 {
590 {
593 }
594 }
597 /* Generate a derived equality against each other member */
599 {
601 Oid eq_op;
610 {
611 /* failed... */
614 }
620 }
621 }
623 /*
624 * generate_base_implied_equalities when EC contains no pseudoconstants
625 */
626 static void
629 {
633 /*
634 * We scan the EC members once and track the last-seen member for each
635 * base relation. When we see another member of the same base relation,
636 * we generate "prev_mem = cur_mem". This results in the minimum number
637 * of derived clauses, but it's possible that it will fail when a
638 * different ordering would succeed. XXX FIXME: use a UNION-FIND
639 * algorithm similar to the way we build merged ECs. (Use a list-of-lists
640 * for each rel.)
641 */
646 {
657 {
659 Oid eq_op;
665 {
666 /* failed... */
669 }
675 }
677 }
681 /*
682 * We also have to make sure that all the Vars used in the member clauses
683 * will be available at any join node we might try to reference them at.
684 * For the moment we force all the Vars to be available at all join nodes
685 * for this eclass. Perhaps this could be improved by doing some
686 * pre-analysis of which members we prefer to join, but it's no worse than
687 * what happened in the pre-8.3 code.
688 */
690 {
693 PVC_INCLUDE_PLACEHOLDERS);
697 }
698 }
700 /*
701 * generate_base_implied_equalities cleanup after failure
702 *
703 * What we must do here is push any zero- or one-relation source RestrictInfos
704 * of the EC back into the main restrictinfo datastructures. Multi-relation
705 * clauses will be regurgitated later by generate_join_implied_equalities().
706 * (We do it this way to maintain continuity with the case that ec_broken
707 * becomes set only after we've gone up a join level or two.)
708 */
709 static void
712 {
716 {
721 }
722 }
725 /*
726 * generate_join_implied_equalities
727 * Generate any join clauses that we can deduce from equivalence classes.
728 *
729 * At a join node, we must enforce restriction clauses sufficient to ensure
730 * that all equivalence-class members computable at that node are equal.
731 * Since the set of clauses to enforce can vary depending on which subset
732 * relations are the inputs, we have to compute this afresh for each join
733 * path pair. Hence a fresh List of RestrictInfo nodes is built and passed
734 * back on each call.
735 *
736 * The results are sufficient for use in merge, hash, and plain nestloop join
737 * methods. We do not worry here about selecting clauses that are optimal
738 * for use in a nestloop-with-inner-indexscan join, however. indxpath.c makes
739 * its own selections of clauses to use, and if the ones we pick here are
740 * redundant with those, the extras will be eliminated in createplan.c.
741 *
742 * Because the same join clauses are likely to be needed multiple times as
743 * we consider different join paths, we avoid generating multiple copies:
744 * whenever we select a particular pair of EquivalenceMembers to join,
745 * we check to see if the pair matches any original clause (in ec_sources)
746 * or previously-built clause (in ec_derives). This saves memory and allows
747 * re-use of information cached in RestrictInfos.
748 */
749 List *
754 {
759 {
763 /* ECs containing consts do not need any further enforcement */
767 /* Single-member ECs won't generate any deductions */
771 /* We can quickly ignore any that don't overlap the join, too */
777 ec,
778 joinrel,
779 outer_rel,
780 inner_rel);
782 /* Recover if we failed to generate required derived clauses */
785 ec,
786 joinrel,
787 outer_rel,
788 inner_rel);
791 }
794 }
796 /*
797 * generate_join_implied_equalities for a still-valid EC
798 */
805 {
812 /*
813 * First, scan the EC to identify member values that are computable at the
814 * outer rel, at the inner rel, or at this relation but not in either
815 * input rel. The outer-rel members should already be enforced equal,
816 * likewise for the inner-rel members. We'll need to create clauses to
817 * enforce that any newly computable members are all equal to each other
818 * as well as to at least one input member, plus enforce at least one
819 * outer-rel member equal to at least one inner-rel member.
820 */
822 {
834 else
836 }
838 /*
839 * First, select the joinclause if needed. We can equate any one outer
840 * member to any one inner member, but we have to find a datatype
841 * combination for which an opfamily member operator exists. If we have
842 * choices, we prefer simple Var members (possibly with RelabelType) since
843 * these are (a) cheapest to compute at runtime and (b) most likely to
844 * have useful statistics. Also, if enable_hashjoin is on, we prefer
845 * operators that are also hashjoinable.
846 */
848 {
856 {
861 {
863 Oid eq_op;
875 score++;
879 score++;
881 score++;
883 {
890 }
891 }
894 }
896 {
897 /* failed... */
900 }
902 /*
903 * Create clause, setting parent_ec to mark it as redundant with other
904 * joinclauses
905 */
908 ec);
911 }
913 /*
914 * Now deal with building restrictions for any expressions that involve
915 * Vars from both sides of the join. We have to equate all of these to
916 * each other as well as to at least one old member (if any).
917 *
918 * XXX as in generate_base_implied_equalities_no_const, we could be a lot
919 * smarter here to avoid unnecessary failures in cross-type situations.
920 * For now, use the same left-to-right method used there.
921 */
923 {
928 /* For now, arbitrarily take the first old_member as the one to use */
933 {
937 {
938 Oid eq_op;
944 {
945 /* failed... */
948 }
949 /* do NOT set parent_ec, this qual is not redundant! */
952 NULL);
955 }
957 }
958 }
961 }
963 /*
964 * generate_join_implied_equalities cleanup after failure
965 *
966 * Return any original RestrictInfos that are enforceable at this join.
967 */
974 {
979 {
986 }
989 }
992 /*
993 * select_equality_operator
994 * Select a suitable equality operator for comparing two EC members
995 *
996 * Returns InvalidOid if no operator can be found for this datatype combination
997 */
998 static Oid
1000 {
1004 {
1006 Oid opno;
1009 BTEqualStrategyNumber);
1012 }
1014 }
1017 /*
1018 * create_join_clause
1019 * Find or make a RestrictInfo comparing the two given EC members
1020 * with the given operator.
1021 *
1022 * parent_ec is either equal to ec (if the clause is a potentially-redundant
1023 * join clause) or NULL (if not). We have to treat this as part of the
1024 * match requirements --- it's possible that a clause comparing the same two
1025 * EMs is a join clause in one join path and a restriction clause in another.
1026 */
1033 {
1036 MemoryContext oldcontext;
1038 /*
1039 * Search to see if we already built a RestrictInfo for this pair of
1040 * EquivalenceMembers. We can use either original source clauses or
1041 * previously-derived clauses. The check on opno is probably redundant,
1042 * but be safe ...
1043 */
1045 {
1052 }
1055 {
1062 }
1064 /*
1065 * Not there, so build it, in planner context so we can re-use it. (Not
1066 * important in normal planning, but definitely so in GEQO.)
1067 */
1076 /* Mark the clause as redundant, or not */
1079 /*
1080 * We can set these now, rather than letting them be looked up later,
1081 * since this is only used after EC merging is complete.
1082 */
1086 /* Mark it as usable with these EMs */
1089 /* and save it for possible re-use */
1095 }
1098 /*
1099 * reconsider_outer_join_clauses
1100 * Re-examine any outer-join clauses that were set aside by
1101 * distribute_qual_to_rels(), and see if we can derive any
1102 * EquivalenceClasses from them. Then, if they were not made
1103 * redundant, push them out into the regular join-clause lists.
1104 *
1105 * When we have mergejoinable clauses A = B that are outer-join clauses,
1106 * we can't blindly combine them with other clauses A = C to deduce B = C,
1107 * since in fact the "equality" A = B won't necessarily hold above the
1108 * outer join (one of the variables might be NULL instead). Nonetheless
1109 * there are cases where we can add qual clauses using transitivity.
1110 *
1111 * One case that we look for here is an outer-join clause OUTERVAR = INNERVAR
1112 * for which there is also an equivalence clause OUTERVAR = CONSTANT.
1113 * It is safe and useful to push a clause INNERVAR = CONSTANT into the
1114 * evaluation of the inner (nullable) relation, because any inner rows not
1115 * meeting this condition will not contribute to the outer-join result anyway.
1116 * (Any outer rows they could join to will be eliminated by the pushed-down
1117 * equivalence clause.)
1118 *
1119 * Note that the above rule does not work for full outer joins; nor is it
1120 * very interesting to consider cases where the generated equivalence clause
1121 * would involve relations outside the outer join, since such clauses couldn't
1122 * be pushed into the inner side's scan anyway. So the restriction to
1123 * outervar = pseudoconstant is not really giving up anything.
1124 *
1125 * For full-join cases, we can only do something useful if it's a FULL JOIN
1126 * USING and a merged column has an equivalence MERGEDVAR = CONSTANT.
1127 * By the time it gets here, the merged column will look like
1128 * COALESCE(LEFTVAR, RIGHTVAR)
1129 * and we will have a full-join clause LEFTVAR = RIGHTVAR that we can match
1130 * the COALESCE expression to. In this situation we can push LEFTVAR = CONSTANT
1131 * and RIGHTVAR = CONSTANT into the input relations, since any rows not
1132 * meeting these conditions cannot contribute to the join result.
1133 *
1134 * Again, there isn't any traction to be gained by trying to deal with
1135 * clauses comparing a mergedvar to a non-pseudoconstant. So we can make
1136 * use of the EquivalenceClasses to search for matching variables that were
1137 * equivalenced to constants. The interesting outer-join clauses were
1138 * accumulated for us by distribute_qual_to_rels.
1139 *
1140 * When we find one of these cases, we implement the changes we want by
1141 * generating a new equivalence clause INNERVAR = CONSTANT (or LEFTVAR, etc)
1142 * and pushing it into the EquivalenceClass structures. This is because we
1143 * may already know that INNERVAR is equivalenced to some other var(s), and
1144 * we'd like the constant to propagate to them too. Note that it would be
1145 * unsafe to merge any existing EC for INNERVAR with the OUTERVAR's EC ---
1146 * that could result in propagating constant restrictions from
1147 * INNERVAR to OUTERVAR, which would be very wrong.
1148 *
1149 * It's possible that the INNERVAR is also an OUTERVAR for some other
1150 * outer-join clause, in which case the process can be repeated. So we repeat
1151 * looping over the lists of clauses until no further deductions can be made.
1152 * Whenever we do make a deduction, we remove the generating clause from the
1153 * lists, since we don't want to make the same deduction twice.
1154 *
1155 * If we don't find any match for a set-aside outer join clause, we must
1156 * throw it back into the regular joinclause processing by passing it to
1157 * distribute_restrictinfo_to_rels(). If we do generate a derived clause,
1158 * however, the outer-join clause is redundant. We still throw it back,
1159 * because otherwise the join will be seen as a clauseless join and avoided
1160 * during join order searching; but we mark it as redundant to keep from
1161 * messing up the joinrel's size estimate. (This behavior means that the
1162 * API for this routine is uselessly complex: we could have just put all
1163 * the clauses into the regular processing initially. We keep it because
1164 * someday we might want to do something else, such as inserting "dummy"
1165 * joinclauses instead of real ones.)
1166 *
1167 * Outer join clauses that are marked outerjoin_delayed are special: this
1168 * condition means that one or both VARs might go to null due to a lower
1169 * outer join. We can still push a constant through the clause, but only
1170 * if its operator is strict; and we *have to* throw the clause back into
1171 * regular joinclause processing. By keeping the strict join clause,
1172 * we ensure that any null-extended rows that are mistakenly generated due
1173 * to suppressing rows not matching the constant will be rejected at the
1174 * upper outer join. (This doesn't work for full-join clauses.)
1175 */
1176 void
1178 {
1184 /* Outer loop repeats until we find no more deductions */
1185 do
1186 {
1189 /* Process the LEFT JOIN clauses */
1192 {
1197 {
1199 /* remove it from the list */
1202 /* we throw it back anyway (see notes above) */
1203 /* but the thrown-back clause has no extra selectivity */
1207 }
1208 else
1210 }
1212 /* Process the RIGHT JOIN clauses */
1215 {
1220 {
1222 /* remove it from the list */
1225 /* we throw it back anyway (see notes above) */
1226 /* but the thrown-back clause has no extra selectivity */
1230 }
1231 else
1233 }
1235 /* Process the FULL JOIN clauses */
1238 {
1243 {
1245 /* remove it from the list */
1248 /* we throw it back anyway (see notes above) */
1249 /* but the thrown-back clause has no extra selectivity */
1253 }
1254 else
1256 }
1259 /* Now, any remaining clauses have to be thrown back */
1261 {
1265 }
1267 {
1271 }
1273 {
1277 }
1278 }
1280 /*
1281 * reconsider_outer_join_clauses for a single LEFT/RIGHT JOIN clause
1282 *
1283 * Returns TRUE if we were able to propagate a constant through the clause.
1284 */
1285 static bool
1288 {
1291 Oid opno,
1292 left_type,
1293 right_type,
1294 inner_datatype;
1295 Relids inner_relids;
1301 /* If clause is outerjoin_delayed, operator must be strict */
1305 /* Extract needed info from the clause */
1308 {
1313 }
1314 else
1315 {
1320 }
1322 /* Scan EquivalenceClasses for a match to outervar */
1324 {
1329 /* Ignore EC unless it contains pseudoconstants */
1332 /* Never match to a volatile EC */
1335 /* It has to match the outer-join clause as to opfamilies, too */
1338 /* Does it contain a match to outervar? */
1341 {
1345 {
1348 }
1349 }
1353 /*
1354 * Yes it does! Try to generate a clause INNERVAR = CONSTANT for each
1355 * CONSTANT in the EC. Note that we must succeed with at least one
1356 * constant before we can decide to throw away the outer-join clause.
1357 */
1360 {
1362 Oid eq_op;
1368 inner_datatype,
1373 innervar,
1375 inner_relids);
1378 }
1380 /*
1381 * If we were able to equate INNERVAR to any constant, report success.
1382 * Otherwise, fall out of the search loop, since we know the OUTERVAR
1383 * appears in at most one EC.
1384 */
1387 else
1389 }
1392 }
1394 /*
1395 * reconsider_outer_join_clauses for a single FULL JOIN clause
1396 *
1397 * Returns TRUE if we were able to propagate a constant through the clause.
1398 */
1399 static bool
1401 {
1404 Oid opno,
1405 left_type,
1406 right_type;
1407 Relids left_relids,
1408 right_relids;
1411 /* Can't use an outerjoin_delayed clause here */
1415 /* Extract needed info from the clause */
1425 {
1433 /* Ignore EC unless it contains pseudoconstants */
1436 /* Never match to a volatile EC */
1439 /* It has to match the outer-join clause as to opfamilies, too */
1443 /*
1444 * Does it contain a COALESCE(leftvar, rightvar) construct?
1445 *
1446 * We can assume the COALESCE() inputs are in the same order as the
1447 * join clause, since both were automatically generated in the cases
1448 * we care about.
1449 *
1450 * XXX currently this may fail to match in cross-type cases because
1451 * the COALESCE will contain typecast operations while the join clause
1452 * may not (if there is a cross-type mergejoin operator available for
1453 * the two column types). Is it OK to strip implicit coercions from
1454 * the COALESCE arguments?
1455 */
1458 {
1461 {
1472 {
1475 }
1476 }
1477 }
1481 /*
1482 * Yes it does! Try to generate clauses LEFTVAR = CONSTANT and
1483 * RIGHTVAR = CONSTANT for each CONSTANT in the EC. Note that we must
1484 * succeed with at least one constant for each var before we can
1485 * decide to throw away the outer-join clause.
1486 */
1489 {
1491 Oid eq_op;
1497 left_type,
1500 {
1502 leftvar,
1504 left_relids);
1507 }
1509 right_type,
1512 {
1514 rightvar,
1516 right_relids);
1519 }
1520 }
1522 /*
1523 * If we were able to equate both vars to constants, we're done, and
1524 * we can throw away the full-join clause as redundant. Moreover, we
1525 * can remove the COALESCE entry from the EC, since the added
1526 * restrictions ensure it will always have the expected value. (We
1527 * don't bother trying to update ec_relids or ec_sources.)
1528 */
1530 {
1533 }
1535 /*
1536 * Otherwise, fall out of the search loop, since we know the COALESCE
1537 * appears in at most one EC (XXX might stop being true if we allow
1538 * stripping of coercions above?)
1539 */
1541 }
1544 }
1547 /*
1548 * exprs_known_equal
1549 * Detect whether two expressions are known equal due to equivalence
1550 * relationships.
1551 *
1552 * Actually, this only shows that the expressions are equal according
1553 * to some opfamily's notion of equality --- but we only use it for
1554 * selectivity estimation, so a fuzzy idea of equality is OK.
1555 *
1556 * Note: does not bother to check for "equal(item1, item2)"; caller must
1557 * check that case if it's possible to pass identical items.
1558 */
1559 bool
1561 {
1565 {
1571 /* Never match to a volatile EC */
1576 {
1583 /* Exit as soon as equality is proven */
1586 }
1587 }
1589 }
1592 /*
1593 * add_child_rel_equivalences
1594 * Search for EC members that reference (only) the parent_rel, and
1595 * add transformed members referencing the child_rel.
1596 *
1597 * We only need to do this for ECs that could generate join conditions,
1598 * since the child members are only used for creating inner-indexscan paths.
1599 *
1600 * parent_rel and child_rel could be derived from appinfo, but since the
1601 * caller has already computed them, we might as well just pass them in.
1602 */
1603 void
1608 {
1612 {
1616 /*
1617 * Won't generate joinclauses if const or single-member (the latter
1618 * test covers the volatile case too)
1619 */
1623 /* No point in searching if parent rel not mentioned in eclass */
1628 {
1631 /* Does it reference (only) parent_rel? */
1633 {
1634 /* Yes, generate transformed child version */
1639 appinfo);
1642 }
1643 }
1644 }
1645 }
1648 /*
1649 * mutate_eclass_expressions
1650 * Apply an expression tree mutator to all expressions stored in
1651 * equivalence classes.
1652 *
1653 * This is a bit of a hack ... it's currently needed only by planagg.c,
1654 * which needs to do a global search-and-replace of MIN/MAX Aggrefs
1655 * after eclasses are already set up. Without changing the eclasses too,
1656 * subsequent matching of ORDER BY clauses would fail.
1657 *
1658 * Note that we assume the mutation won't affect relation membership or any
1659 * other properties we keep track of (which is a bit bogus, but by the time
1660 * planagg.c runs, it no longer matters). Also we must be called in the
1661 * main planner memory context.
1662 */
1663 void
1667 {
1671 {
1676 {
1681 }
1682 }
1683 }
1686 /*
1687 * find_eclass_clauses_for_index_join
1688 * Create joinclauses usable for a nestloop-with-inner-indexscan
1689 * scanning the given inner rel with the specified set of outer rels.
1690 */
1691 List *
1693 Relids outer_relids)
1694 {
1700 {
1704 /*
1705 * Won't generate joinclauses if const or single-member (the latter
1706 * test covers the volatile case too)
1707 */
1711 /*
1712 * No point in searching if rel not mentioned in eclass (but we can't
1713 * tell that for a child rel).
1714 */
1718 /* ... nor if no overlap with outer_relids */
1722 /* Scan members, looking for indexable columns */
1724 {
1734 /*
1735 * Found one, so try to generate a join clause. This is like
1736 * generate_join_implied_equalities_normal, except simpler since
1737 * our only preference item is to pick a Var on the outer side. We
1738 * only need one join clause per index col.
1739 */
1741 {
1743 Oid eq_op;
1758 }
1761 {
1762 /* Found a suitable joinclause */
1765 /* set parent_ec to mark as redundant with other joinclauses */
1768 cur_ec);
1772 /*
1773 * Note: we keep scanning here because we want to provide a
1774 * clause for every possible indexcol.
1775 */
1776 }
1777 }
1778 }
1781 }
1784 /*
1785 * have_relevant_eclass_joinclause
1786 * Detect whether there is an EquivalenceClass that could produce
1787 * a joinclause between the two given relations.
1788 *
1789 * This is essentially a very cut-down version of
1790 * generate_join_implied_equalities(). Note it's OK to occasionally say "yes"
1791 * incorrectly. Hence we don't bother with details like whether the lack of a
1792 * cross-type operator might prevent the clause from actually being generated.
1793 */
1794 bool
1797 {
1801 {
1807 /*
1808 * Won't generate joinclauses if single-member (this test covers the
1809 * volatile case too)
1810 */
1814 /*
1815 * Note we don't test ec_broken; if we did, we'd need a separate code
1816 * path to look through ec_sources. Checking the members anyway is OK
1817 * as a possibly-overoptimistic heuristic.
1818 *
1819 * We don't test ec_has_const either, even though a const eclass won't
1820 * generate real join clauses. This is because if we had "WHERE a.x =
1821 * b.y and a.x = 42", it is worth considering a join between a and b,
1822 * since the join result is likely to be small even though it'll end
1823 * up being an unqualified nestloop.
1824 */
1826 /* Needn't scan if it couldn't contain members from each rel */
1831 /* Scan the EC to see if it has member(s) in each rel */
1834 {
1840 {
1844 }
1846 {
1850 }
1851 }
1855 }
1858 }
1861 /*
1862 * has_relevant_eclass_joinclause
1863 * Detect whether there is an EquivalenceClass that could produce
1864 * a joinclause between the given relation and anything else.
1865 *
1866 * This is the same as have_relevant_eclass_joinclause with the other rel
1867 * implicitly defined as "everything else in the query".
1868 */
1869 bool
1871 {
1875 {
1881 /*
1882 * Won't generate joinclauses if single-member (this test covers the
1883 * volatile case too)
1884 */
1888 /*
1889 * Note we don't test ec_broken; if we did, we'd need a separate code
1890 * path to look through ec_sources. Checking the members anyway is OK
1891 * as a possibly-overoptimistic heuristic.
1892 *
1893 * We don't test ec_has_const either, even though a const eclass won't
1894 * generate real join clauses. This is because if we had "WHERE a.x =
1895 * b.y and a.x = 42", it is worth considering a join between a and b,
1896 * since the join result is likely to be small even though it'll end
1897 * up being an unqualified nestloop.
1898 */
1900 /* Needn't scan if it couldn't contain members from each rel */
1905 /* Scan the EC to see if it has member(s) in each rel */
1908 {
1914 {
1918 }
1920 {
1924 }
1925 }
1929 }
1932 }
1935 /*
1936 * eclass_useful_for_merging
1937 * Detect whether the EC could produce any mergejoinable join clauses
1938 * against the specified relation.
1939 *
1940 * This is just a heuristic test and doesn't have to be exact; it's better
1941 * to say "yes" incorrectly than "no". Hence we don't bother with details
1942 * like whether the lack of a cross-type operator might prevent the clause
1943 * from actually being generated.
1944 */
1945 bool
1948 {
1953 /*
1954 * Won't generate joinclauses if const or single-member (the latter test
1955 * covers the volatile case too)
1956 */
1960 /*
1961 * Note we don't test ec_broken; if we did, we'd need a separate code path
1962 * to look through ec_sources. Checking the members anyway is OK as a
1963 * possibly-overoptimistic heuristic.
1964 */
1966 /* If rel already includes all members of eclass, no point in searching */
1970 /* To join, we need a member not in the given rel */
1972 {
1978 }
1981 }