-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Move create_physical_expr to phy-expr-common #3 #10188
Conversation
Hi @jayzhan211 -- if we merge this one, does it close #10176 and #10144 ? |
Yes! |
It depends on you and other reviewers, If you don't mind the large PR, definitely it is nice we can merge this one. I didn't merge #10144 because I'm also curious about what is it like at the final PR, make sure not all the things are moved to common |
Signed-off-by: jayzhan211 <jayzhan211@gmail.com>
Signed-off-by: jayzhan211 <jayzhan211@gmail.com>
Signed-off-by: jayzhan211 <jayzhan211@gmail.com>
Signed-off-by: jayzhan211 <jayzhan211@gmail.com>
Signed-off-by: jayzhan211 <jayzhan211@gmail.com>
Signed-off-by: jayzhan211 <jayzhan211@gmail.com>
1adfcde
to
da795aa
Compare
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.
Thank you for this @jayzhan211
I spent some time reviewing this PR this morining
One thing I am missing is the big picture description / story of "what code belongs in what crate". I suspect there is a good story here but I can't quite figure it out.
In this case, I think getting the larger story straight will help avoid churn / code moving back and forth unecessairly. The larger story is also likely the key to understanding the end state.
create_physical_expr
As I understand it, this PR is part of the larger quest to move aggregate functions out of datafusion-physical-expr #8708
In my mind, create_physical_expr
is a big switch statement between Expr
--> Arc<dyn PhysicalExpr>
Once we have created a Arc<dyn PhysicalExpr>
I don't really understand how/why we would ever get an Expr
that we need to convert back to Arc<dyn PhysicalExpr>
again.
End state of dependencies??
Is the eventual plan to have something like the following? If so, I don't understand why the functions-aggregates
needs to depends on create_physical_erxpr
graph TD;
functions-aggregates-->physical-expr-common;
physical-expr-->physical-expr-common;
core-->functions-aggregates;
core-->physical-expr;
Here is another suggestion: #10074 (comment) |
I agree, but it turns out I didn't find a way to reuse
I agree with the graph, which is in my mind too. |
If we can move |
Which issue does this PR close?
Closes #10176
Closes #10074
Closes #10144
All in one in this PR.
Rationale for this change
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?