xuyangzhong commented on pull request #17272: URL: https://github.com/apache/flink/pull/17272#issuecomment-918768165
Hi, @zjuwangg The main reason is that in FlinkBatchProgram, this iterator time is set with 5. In order to be consistent, i rewrite the number 5 here. I tried to find why we need to set iterations here. Actually, I think this aims to pushdown the filter condition into the join condition and can continue optimizing the join condition several times. For example, in table api, the api named 'join' and 'where' will create a join relNode with a true condition and a fliter above the join relNode. The real condition we need will be set in the filter relNode. The optimized program will do JOIN_PREDICATE_REWRITE_RULES first, which will extract the join condition, and then do FILTER_PREPARE_RULES, which will push the filter condition into the join condition. However, if we don't set the iterator, JOIN_PREDICATE_REWRITE_RULES finds that the join condition is always True, and will do nothing, which is not in our expectation. I reversed the order of executing these two rules and get the result i expected. I think the iterator time which means the repeat execution times will help avoid this kind of problem by repeating executing these two rules many times, which even can improve the problem of recursive optimization. -- 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: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
