github-actions[bot] commented on code in PR #64559:
URL: https://github.com/apache/doris/pull/64559#discussion_r3419129205
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/jobs/cascades/OptimizeGroupExpressionJob.java:
##########
@@ -93,9 +93,7 @@ private List<Rule> getExplorationRules(CascadesContext
cascadesContext) {
private List<Rule> getJoinRules() {
boolean isDisableJoinReorder =
context.getCascadesContext().getConnectContext().getSessionVariable()
.isDisableJoinReorder()
- || context.getCascadesContext().isLeadingDisableJoinReorder()
- ||
context.getCascadesContext().getMemo().getGroupExpressionsSize() >
context.getCascadesContext()
Review Comment:
This removes the only guard that stopped join rules before they were
scheduled once the memo exceeded `memo_max_group_expression_size`. The
remaining guard in `ApplyRuleJob` does not cover `LOGICAL_JOIN_COMMUTE`
(`rule.getRuleType() != RuleType.LOGICAL_JOIN_COMMUTE`), and all of the join
reorder rule sets start with a `JoinCommute` rule. So after the memo crosses
the configured limit, `getJoinRules()` still schedules commute jobs and those
jobs can keep adding swapped join expressions; the old code returned no join
rules at that point. For large joins this defeats the safety purpose of
`memo_max_group_expression_size` and can continue growing the memo past the
limit. Please keep an equivalent memo-size check before returning join rules,
or add a separate cutoff that also prevents join commute once the limit has
been reached.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
