-
Notifications
You must be signed in to change notification settings - Fork 1.9k
fix: TableScan should recurse into provider logical plan in map_children #19282
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
base: main
Are you sure you want to change the base?
Conversation
leoyvens
left a comment
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.
Thanks for jumping onto this issue so quickly! I just have a concern about the fn replace_logical_plan, I'm hoping there is a simpler way.
datafusion/expr/src/table_source.rs
Outdated
| None | ||
| } | ||
|
|
||
| fn replace_logical_plan( |
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.
Would it be possible to avoid adding a method to the TableSource trait?
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.
Hey @leoyvens , can u please review . I removed any changes made to TableSource trait .
588864a to
e74ca7a
Compare
leoyvens
left a comment
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.
This addresses my issue
martin-g
left a comment
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.
I am not sure how problematic this is but now the visit method (apply_children) is not symmetrical with the rewrite method (map_children).
apply_children does not visit the inner plan of TableScan.
|
run benchmark sql_planner |
|
🤖 |
|
🤖: Benchmark completed Details
|
Should i rewrite the |
|
I'm not the best person to answer this question. |
Which issue does this PR close?
Rationale for this change
LogicalPlan::TableScan is currently treated as a leaf node in map_children, but some table providers (such as views) expose their own logical plan via TableSource::get_logical_plan().
Because of this incorrect leaf assumption, logical plan visitors and optimizer passes fail to recurse into the underlying logical plan. This leads to missed optimizations and incomplete rewrites when a scan represents a view or other provider-defined logical plan.
What changes are included in this PR?
TableSourcereturns a logical planTableSourceusingreplace_logical_planafter transformationtest_table_scan_with_inner_plan_is_visitedensures recursion occurs for providers with an inner plantest_table_scan_without_inner_plan_is_not_visitedensures behavior remains unchanged when no inner plan existsAre these changes tested?
Yes.
Two dedicated unit tests validate:
Are there any user-facing changes?
No