-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-54865][CONNECT][SQL] Add foreachWithSubqueriesAndPruning method to QueryPlan #53637
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -630,6 +630,20 @@ abstract class QueryPlan[PlanType <: QueryPlan[PlanType]] | |
| foreach(actualFunc) | ||
| } | ||
|
|
||
| /** | ||
| * A variant of [[foreachWithSubqueries]] with pruning support. | ||
| * Only traverses nodes that match the given condition. | ||
| */ | ||
| def foreachWithSubqueriesAndPruning( | ||
| cond: TreePatternBits => Boolean)(f: PlanType => Unit): Unit = { | ||
| if (!cond.apply(this)) { | ||
| return | ||
| } | ||
| f(this) | ||
| subqueries.foreach(_.foreachWithSubqueriesAndPruning(cond)(f)) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. or it's actually interleaved in
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The traversal order of After taking a closer look at the code, I think it may be a style choice for So the correctness may not be affected, but style-wise, it makes more sense to move the pruning logic to TreeNode.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Discussed with @cloud-fan offline, while the current convention is to let TreeNode methods to handle plan traversal logic (including withPruning), for |
||
| children.foreach(_.foreachWithSubqueriesAndPruning(cond)(f)) | ||
| } | ||
|
|
||
| /** | ||
| * A variant of `collect`. This method not only apply the given function to all elements in this | ||
| * plan, also considering all the plans in its (nested) subqueries. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
other pruning methods also have a ruleId parameter, shall we follow?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, ruleId is not applicable here, since it is used for transformation—it represents the transformation rule ID. Also, ruleId is not used by default, as the default value is UnknownRuleId.
If we really need this parameter, we can extend it later (less is more).