You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@calcite.apache.org by GitBox <gi...@apache.org> on 2022/06/13 09:34:11 UTC

[GitHub] [calcite] rubenada commented on a diff in pull request #2831: [CALCITE-5177] Query loses hint after decorrelation (minor follow-up)

rubenada commented on code in PR #2831:
URL: https://github.com/apache/calcite/pull/2831#discussion_r895519624


##########
core/src/main/java/org/apache/calcite/plan/RelOptUtil.java:
##########
@@ -475,6 +475,10 @@ public static RelNode copyRelHints(RelNode originalRel, RelNode newRel) {
    * or {@code newRel} directly if one of them are not {@link Hintable}
    */
   public static RelNode copyRelHints(RelNode originalRel, RelNode newRel, boolean filterHints) {
+    if (originalRel == newRel && !filterHints) {
+      return originalRel;

Review Comment:
   If we have `filterHints` we can end up with a "new rel result" right? The result rel will be the originalRel (or newRel) with potentially fewer hints (if at least one of the original hints is filtered out). Maybe it is a far-fetched scenario that does not happen in practice, but I guess it is theoretically possible, so I'd prefer to be have this check.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@calcite.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org