• R/O
  • HTTP
  • SSH
  • HTTPS

pg_hint_plan: コミット

firtst release


コミットメタ情報

リビジョン54c5bcbdcd8560d591e1071034fab6e3f5644c0b (tree)
日時2017-07-27 19:16:51
作者Kyotaro Horiguchi <horiguchi.kyotaro@lab....>
コミッターKyotaro Horiguchi

ログメッセージ

Make core.c up to date.

Apply changes in corresponding core code.

変更サマリ

差分

--- a/core.c
+++ b/core.c
@@ -44,7 +44,7 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
4444
4545 /*
4646 * Generate access paths for each member relation, and remember the
47- * cheapest path for each one. Also, identify all pathkeys (orderings)
47+ * cheapest path for each one. Also, identify all pathkeys (orderings)
4848 * and parameterizations (required_outer sets) available for the member
4949 * relations.
5050 */
@@ -94,7 +94,7 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
9494
9595 /*
9696 * Collect lists of all the available path orderings and
97- * parameterizations for all the children. We use these as a
97+ * parameterizations for all the children. We use these as a
9898 * heuristic to indicate which sort orderings and parameterizations we
9999 * should build Append and MergeAppend paths for.
100100 */
@@ -180,7 +180,7 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
180180 * so that not that many cases actually get considered here.)
181181 *
182182 * The Append node itself cannot enforce quals, so all qual checking must
183- * be done in the child paths. This means that to have a parameterized
183+ * be done in the child paths. This means that to have a parameterized
184184 * Append path, we must have the exact same parameterization for each
185185 * child path; otherwise some children might be failing to check the
186186 * moved-down quals. To make them match up, we can try to increase the
@@ -351,7 +351,7 @@ get_cheapest_parameterized_child_path(PlannerInfo *root, RelOptInfo *rel,
351351 * joinquals to be checked within the path's scan. However, some existing
352352 * paths might check the available joinquals already while others don't;
353353 * therefore, it's not clear which existing path will be cheapest after
354- * reparameterization. We have to go through them all and find out.
354+ * reparameterization. We have to go through them all and find out.
355355 */
356356 cheapest = NULL;
357357 foreach(lc, rel->pathlist)
@@ -395,10 +395,15 @@ get_cheapest_parameterized_child_path(PlannerInfo *root, RelOptInfo *rel,
395395 * accumulate_append_subpath
396396 * Add a subpath to the list being built for an Append or MergeAppend
397397 *
398- * It's possible that the child is itself an Append path, in which case
399- * we can "cut out the middleman" and just add its child paths to our
400- * own list. (We don't try to do this earlier because we need to
401- * apply both levels of transformation to the quals.)
398+ * It's possible that the child is itself an Append or MergeAppend path, in
399+ * which case we can "cut out the middleman" and just add its child paths to
400+ * our own list. (We don't try to do this earlier because we need to apply
401+ * both levels of transformation to the quals.)
402+ *
403+ * Note that if we omit a child MergeAppend in this way, we are effectively
404+ * omitting a sort step, which seems fine: if the parent is to be an Append,
405+ * its result would be unsorted anyway, while if the parent is to be a
406+ * MergeAppend, there's no point in a separate sort on a child.
402407 */
403408 static List *
404409 accumulate_append_subpath(List *subpaths, Path *path)
@@ -410,6 +415,13 @@ accumulate_append_subpath(List *subpaths, Path *path)
410415 /* list_copy is important here to avoid sharing list substructure */
411416 return list_concat(subpaths, list_copy(apath->subpaths));
412417 }
418+ else if (IsA(path, MergeAppendPath))
419+ {
420+ MergeAppendPath *mpath = (MergeAppendPath *) path;
421+
422+ /* list_copy is important here to avoid sharing list substructure */
423+ return list_concat(subpaths, list_copy(mpath->subpaths));
424+ }
413425 else
414426 return lappend(subpaths, path);
415427 }
@@ -423,7 +435,7 @@ accumulate_append_subpath(List *subpaths, Path *path)
423435 * independent jointree items in the query. This is > 1.
424436 *
425437 * 'initial_rels' is a list of RelOptInfo nodes for each independent
426- * jointree item. These are the components to be joined together.
438+ * jointree item. These are the components to be joined together.
427439 * Note that levels_needed == list_length(initial_rels).
428440 *
429441 * Returns the final level of join relations, i.e., the relation that is
@@ -439,7 +451,7 @@ accumulate_append_subpath(List *subpaths, Path *path)
439451 * needed for these paths need have been instantiated.
440452 *
441453 * Note to plugin authors: the functions invoked during standard_join_search()
442- * modify root->join_rel_list and root->join_rel_hash. If you want to do more
454+ * modify root->join_rel_list and root->join_rel_hash. If you want to do more
443455 * than one join-order search, you'll probably need to save and restore the
444456 * original states of those data structures. See geqo_eval() for an example.
445457 */
@@ -690,7 +702,7 @@ join_search_one_level(PlannerInfo *root, int level)
690702
691703 /*----------
692704 * When special joins are involved, there may be no legal way
693- * to make an N-way join for some values of N. For example consider
705+ * to make an N-way join for some values of N. For example consider
694706 *
695707 * SELECT ... FROM t1 WHERE
696708 * x IN (SELECT ... FROM t2,t3 WHERE ...) AND
@@ -807,13 +819,11 @@ join_is_legal(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
807819 SpecialJoinInfo *match_sjinfo;
808820 bool reversed;
809821 bool unique_ified;
810- bool is_valid_inner;
811- bool lateral_fwd;
812- bool lateral_rev;
822+ bool must_be_leftjoin;
813823 ListCell *l;
814824
815825 /*
816- * Ensure output params are set on failure return. This is just to
826+ * Ensure output params are set on failure return. This is just to
817827 * suppress uninitialized-variable warnings from overly anal compilers.
818828 */
819829 *sjinfo_p = NULL;
@@ -821,13 +831,13 @@ join_is_legal(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
821831
822832 /*
823833 * If we have any special joins, the proposed join might be illegal; and
824- * in any case we have to determine its join type. Scan the join info
825- * list for conflicts.
834+ * in any case we have to determine its join type. Scan the join info
835+ * list for matches and conflicts.
826836 */
827837 match_sjinfo = NULL;
828838 reversed = false;
829839 unique_ified = false;
830- is_valid_inner = true;
840+ must_be_leftjoin = false;
831841
832842 foreach(l, root->join_info_list)
833843 {
@@ -878,7 +888,8 @@ join_is_legal(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
878888 * If one input contains min_lefthand and the other contains
879889 * min_righthand, then we can perform the SJ at this join.
880890 *
881- * Barf if we get matches to more than one SJ (is that possible?)
891+ * Reject if we get matches to more than one SJ; that implies we're
892+ * considering something that's not really valid.
882893 */
883894 if (bms_is_subset(sjinfo->min_lefthand, rel1->relids) &&
884895 bms_is_subset(sjinfo->min_righthand, rel2->relids))
@@ -943,90 +954,184 @@ join_is_legal(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
943954 }
944955 else
945956 {
946- /*----------
947- * Otherwise, the proposed join overlaps the RHS but isn't
948- * a valid implementation of this SJ. It might still be
949- * a legal join, however. If both inputs overlap the RHS,
950- * assume that it's OK. Since the inputs presumably got past
951- * this function's checks previously, they can't overlap the
952- * LHS and their violations of the RHS boundary must represent
953- * SJs that have been determined to commute with this one.
954- * We have to allow this to work correctly in cases like
955- * (a LEFT JOIN (b JOIN (c LEFT JOIN d)))
956- * when the c/d join has been determined to commute with the join
957- * to a, and hence d is not part of min_righthand for the upper
958- * join. It should be legal to join b to c/d but this will appear
959- * as a violation of the upper join's RHS.
960- * Furthermore, if one input overlaps the RHS and the other does
961- * not, we should still allow the join if it is a valid
962- * implementation of some other SJ. We have to allow this to
963- * support the associative identity
964- * (a LJ b on Pab) LJ c ON Pbc = a LJ (b LJ c ON Pbc) on Pab
965- * since joining B directly to C violates the lower SJ's RHS.
966- * We assume that make_outerjoininfo() set things up correctly
967- * so that we'll only match to some SJ if the join is valid.
968- * Set flag here to check at bottom of loop.
969- *----------
957+ /*
958+ * Otherwise, the proposed join overlaps the RHS but isn't a valid
959+ * implementation of this SJ. But don't panic quite yet: the RHS
960+ * violation might have occurred previously, in one or both input
961+ * relations, in which case we must have previously decided that
962+ * it was OK to commute some other SJ with this one. If we need
963+ * to perform this join to finish building up the RHS, rejecting
964+ * it could lead to not finding any plan at all. (This can occur
965+ * because of the heuristics elsewhere in this file that postpone
966+ * clauseless joins: we might not consider doing a clauseless join
967+ * within the RHS until after we've performed other, validly
968+ * commutable SJs with one or both sides of the clauseless join.)
969+ * This consideration boils down to the rule that if both inputs
970+ * overlap the RHS, we can allow the join --- they are either
971+ * fully within the RHS, or represent previously-allowed joins to
972+ * rels outside it.
970973 */
971- if (sjinfo->jointype != JOIN_SEMI &&
972- bms_overlap(rel1->relids, sjinfo->min_righthand) &&
974+ if (bms_overlap(rel1->relids, sjinfo->min_righthand) &&
973975 bms_overlap(rel2->relids, sjinfo->min_righthand))
974- {
975- /* seems OK */
976- Assert(!bms_overlap(joinrelids, sjinfo->min_lefthand));
977- }
978- else
979- is_valid_inner = false;
976+ continue; /* assume valid previous violation of RHS */
977+
978+ /*
979+ * The proposed join could still be legal, but only if we're
980+ * allowed to associate it into the RHS of this SJ. That means
981+ * this SJ must be a LEFT join (not SEMI or ANTI, and certainly
982+ * not FULL) and the proposed join must not overlap the LHS.
983+ */
984+ if (sjinfo->jointype != JOIN_LEFT ||
985+ bms_overlap(joinrelids, sjinfo->min_lefthand))
986+ return false; /* invalid join path */
987+
988+ /*
989+ * To be valid, the proposed join must be a LEFT join; otherwise
990+ * it can't associate into this SJ's RHS. But we may not yet have
991+ * found the SpecialJoinInfo matching the proposed join, so we
992+ * can't test that yet. Remember the requirement for later.
993+ */
994+ must_be_leftjoin = true;
980995 }
981996 }
982997
983998 /*
984- * Fail if violated some SJ's RHS and didn't match to another SJ. However,
985- * "matching" to a semijoin we are implementing by unique-ification
986- * doesn't count (think: it's really an inner join).
999+ * Fail if violated any SJ's RHS and didn't match to a LEFT SJ: the
1000+ * proposed join can't associate into an SJ's RHS.
1001+ *
1002+ * Also, fail if the proposed join's predicate isn't strict; we're
1003+ * essentially checking to see if we can apply outer-join identity 3, and
1004+ * that's a requirement. (This check may be redundant with checks in
1005+ * make_outerjoininfo, but I'm not quite sure, and it's cheap to test.)
9871006 */
988- if (!is_valid_inner &&
989- (match_sjinfo == NULL || unique_ified))
1007+ if (must_be_leftjoin &&
1008+ (match_sjinfo == NULL ||
1009+ match_sjinfo->jointype != JOIN_LEFT ||
1010+ !match_sjinfo->lhs_strict))
9901011 return false; /* invalid join path */
9911012
9921013 /*
9931014 * We also have to check for constraints imposed by LATERAL references.
994- * The proposed rels could each contain lateral references to the other,
995- * in which case the join is impossible. If there are lateral references
996- * in just one direction, then the join has to be done with a nestloop
997- * with the lateral referencer on the inside. If the join matches an SJ
998- * that cannot be implemented by such a nestloop, the join is impossible.
9991015 */
1000- lateral_fwd = lateral_rev = false;
1001- foreach(l, root->lateral_info_list)
1016+ if (root->hasLateralRTEs)
10021017 {
1003- LateralJoinInfo *ljinfo = (LateralJoinInfo *) lfirst(l);
1018+ bool lateral_fwd;
1019+ bool lateral_rev;
1020+ Relids join_lateral_rels;
10041021
1005- if (bms_is_subset(ljinfo->lateral_rhs, rel2->relids) &&
1006- bms_overlap(ljinfo->lateral_lhs, rel1->relids))
1022+ /*
1023+ * The proposed rels could each contain lateral references to the
1024+ * other, in which case the join is impossible. If there are lateral
1025+ * references in just one direction, then the join has to be done with
1026+ * a nestloop with the lateral referencer on the inside. If the join
1027+ * matches an SJ that cannot be implemented by such a nestloop, the
1028+ * join is impossible.
1029+ *
1030+ * Also, if the lateral reference is only indirect, we should reject
1031+ * the join; whatever rel(s) the reference chain goes through must be
1032+ * joined to first.
1033+ *
1034+ * Another case that might keep us from building a valid plan is the
1035+ * implementation restriction described by have_dangerous_phv().
1036+ */
1037+ lateral_fwd = bms_overlap(rel1->relids, rel2->lateral_relids);
1038+ lateral_rev = bms_overlap(rel2->relids, rel1->lateral_relids);
1039+ if (lateral_fwd && lateral_rev)
1040+ return false; /* have lateral refs in both directions */
1041+ if (lateral_fwd)
10071042 {
10081043 /* has to be implemented as nestloop with rel1 on left */
1009- if (lateral_rev)
1010- return false; /* have lateral refs in both directions */
1011- lateral_fwd = true;
1012- if (!bms_is_subset(ljinfo->lateral_lhs, rel1->relids))
1013- return false; /* rel1 can't compute the required parameter */
10141044 if (match_sjinfo &&
1015- (reversed || match_sjinfo->jointype == JOIN_FULL))
1045+ (reversed ||
1046+ unique_ified ||
1047+ match_sjinfo->jointype == JOIN_FULL))
10161048 return false; /* not implementable as nestloop */
1049+ /* check there is a direct reference from rel2 to rel1 */
1050+ foreach(l, root->lateral_info_list)
1051+ {
1052+ LateralJoinInfo *ljinfo = (LateralJoinInfo *) lfirst(l);
1053+
1054+ if (bms_is_subset(ljinfo->lateral_rhs, rel2->relids) &&
1055+ bms_is_subset(ljinfo->lateral_lhs, rel1->relids))
1056+ break;
1057+ }
1058+ if (l == NULL)
1059+ return false; /* only indirect refs, so reject */
1060+ /* check we won't have a dangerous PHV */
1061+ if (have_dangerous_phv(root, rel1->relids, rel2->lateral_relids))
1062+ return false; /* might be unable to handle required PHV */
10171063 }
1018- if (bms_is_subset(ljinfo->lateral_rhs, rel1->relids) &&
1019- bms_overlap(ljinfo->lateral_lhs, rel2->relids))
1064+ else if (lateral_rev)
10201065 {
10211066 /* has to be implemented as nestloop with rel2 on left */
1022- if (lateral_fwd)
1023- return false; /* have lateral refs in both directions */
1024- lateral_rev = true;
1025- if (!bms_is_subset(ljinfo->lateral_lhs, rel2->relids))
1026- return false; /* rel2 can't compute the required parameter */
10271067 if (match_sjinfo &&
1028- (!reversed || match_sjinfo->jointype == JOIN_FULL))
1068+ (!reversed ||
1069+ unique_ified ||
1070+ match_sjinfo->jointype == JOIN_FULL))
10291071 return false; /* not implementable as nestloop */
1072+ /* check there is a direct reference from rel1 to rel2 */
1073+ foreach(l, root->lateral_info_list)
1074+ {
1075+ LateralJoinInfo *ljinfo = (LateralJoinInfo *) lfirst(l);
1076+
1077+ if (bms_is_subset(ljinfo->lateral_rhs, rel1->relids) &&
1078+ bms_is_subset(ljinfo->lateral_lhs, rel2->relids))
1079+ break;
1080+ }
1081+ if (l == NULL)
1082+ return false; /* only indirect refs, so reject */
1083+ /* check we won't have a dangerous PHV */
1084+ if (have_dangerous_phv(root, rel2->relids, rel1->lateral_relids))
1085+ return false; /* might be unable to handle required PHV */
1086+ }
1087+
1088+ /*
1089+ * LATERAL references could also cause problems later on if we accept
1090+ * this join: if the join's minimum parameterization includes any rels
1091+ * that would have to be on the inside of an outer join with this join
1092+ * rel, then it's never going to be possible to build the complete
1093+ * query using this join. We should reject this join not only because
1094+ * it'll save work, but because if we don't, the clauseless-join
1095+ * heuristics might think that legality of this join means that some
1096+ * other join rel need not be formed, and that could lead to failure
1097+ * to find any plan at all. We have to consider not only rels that
1098+ * are directly on the inner side of an OJ with the joinrel, but also
1099+ * ones that are indirectly so, so search to find all such rels.
1100+ */
1101+ join_lateral_rels = min_join_parameterization(root, joinrelids,
1102+ rel1, rel2);
1103+ if (join_lateral_rels)
1104+ {
1105+ Relids join_plus_rhs = bms_copy(joinrelids);
1106+ bool more;
1107+
1108+ do
1109+ {
1110+ more = false;
1111+ foreach(l, root->join_info_list)
1112+ {
1113+ SpecialJoinInfo *sjinfo = (SpecialJoinInfo *) lfirst(l);
1114+
1115+ if (bms_overlap(sjinfo->min_lefthand, join_plus_rhs) &&
1116+ !bms_is_subset(sjinfo->min_righthand, join_plus_rhs))
1117+ {
1118+ join_plus_rhs = bms_add_members(join_plus_rhs,
1119+ sjinfo->min_righthand);
1120+ more = true;
1121+ }
1122+ /* full joins constrain both sides symmetrically */
1123+ if (sjinfo->jointype == JOIN_FULL &&
1124+ bms_overlap(sjinfo->min_righthand, join_plus_rhs) &&
1125+ !bms_is_subset(sjinfo->min_lefthand, join_plus_rhs))
1126+ {
1127+ join_plus_rhs = bms_add_members(join_plus_rhs,
1128+ sjinfo->min_lefthand);
1129+ more = true;
1130+ }
1131+ }
1132+ } while (more);
1133+ if (bms_overlap(join_plus_rhs, join_lateral_rels))
1134+ return false; /* will not be able to join to some RHS rel */
10301135 }
10311136 }
10321137
@@ -1040,11 +1145,11 @@ join_is_legal(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
10401145 * has_join_restriction
10411146 * Detect whether the specified relation has join-order restrictions,
10421147 * due to being inside an outer join or an IN (sub-SELECT),
1043- * or participating in any LATERAL references.
1148+ * or participating in any LATERAL references or multi-rel PHVs.
10441149 *
10451150 * Essentially, this tests whether have_join_order_restriction() could
10461151 * succeed with this rel and some other one. It's OK if we sometimes
1047- * say "true" incorrectly. (Therefore, we don't bother with the relatively
1152+ * say "true" incorrectly. (Therefore, we don't bother with the relatively
10481153 * expensive has_legal_joinclause test.)
10491154 */
10501155 static bool
@@ -1052,12 +1157,15 @@ has_join_restriction(PlannerInfo *root, RelOptInfo *rel)
10521157 {
10531158 ListCell *l;
10541159
1055- foreach(l, root->lateral_info_list)
1160+ if (rel->lateral_relids != NULL || rel->lateral_referencers != NULL)
1161+ return true;
1162+
1163+ foreach(l, root->placeholder_list)
10561164 {
1057- LateralJoinInfo *ljinfo = (LateralJoinInfo *) lfirst(l);
1165+ PlaceHolderInfo *phinfo = (PlaceHolderInfo *) lfirst(l);
10581166
1059- if (bms_is_subset(ljinfo->lateral_rhs, rel->relids) ||
1060- bms_overlap(ljinfo->lateral_lhs, rel->relids))
1167+ if (bms_is_subset(rel->relids, phinfo->ph_eval_at) &&
1168+ !bms_equal(rel->relids, phinfo->ph_eval_at))
10611169 return true;
10621170 }
10631171
@@ -1100,7 +1208,7 @@ is_dummy_rel(RelOptInfo *rel)
11001208 * dummy.
11011209 *
11021210 * Also, when called during GEQO join planning, we are in a short-lived
1103- * memory context. We must make sure that the dummy path attached to a
1211+ * memory context. We must make sure that the dummy path attached to a
11041212 * baserel survives the GEQO cycle, else the baserel is trashed for future
11051213 * GEQO cycles. On the other hand, when we are marking a joinrel during GEQO,
11061214 * we don't want the dummy path to clutter the main planning context. Upshot
旧リポジトリブラウザで表示