-
Notifications
You must be signed in to change notification settings - Fork 1.7k
chore: deprecate ValuesExec in favour of MemoryExec
#14032
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
Conversation
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 @jonathanc-n -- this one is looking nice 👌
| .collect::<Result<Vec<Arc<dyn PhysicalExpr>>>>() | ||
| }) | ||
| .collect::<Result<Vec<_>>>()?; | ||
| #[allow(deprecated)] // TODO: Remove in favour of MemoryExec |
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.
In this PR I think it would be good to port this code (in the physical planner) to use MemoryExec -- that way queries will run through MemoryExec and we will confidence that ValuesExec can really be removed
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.
@alamb Should be fine now
Co-authored-by: Andrew Lamb <[email protected]>
| ) | ||
| } | ||
|
|
||
| fn compute_properties_as_value(schema: SchemaRef) -> PlanProperties { |
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 think compute_properties could be reuse here. vec![batches] is len=1, pass ordering with &[].
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.
is this something we should do prior to merging the PR?
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.
@alamb Yes, just added it
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 @jonathanc-n and @jayzhan211
The only thing I am not sure if we should do prior to merge is @jayzhan211's comment
https://github.com/apache/datafusion/pull/14032/files#r1907047878
| .collect::<Result<Vec<_>>>()?; | ||
| let value_exec = ValuesExec::try_new(SchemaRef::new(exec_schema), exprs)?; | ||
| let value_exec = | ||
| MemoryExec::try_new_as_values(SchemaRef::new(exec_schema), exprs)?; |
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.
👍
| ) | ||
| } | ||
|
|
||
| fn compute_properties_as_value(schema: SchemaRef) -> PlanProperties { |
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.
is this something we should do prior to merging the PR?
|
Thanks again @jonathanc-n and @jayzhan211 -- I merged up to resolve a conflict and will plan to merge when the tests are clean |
|
🚀 |
|
BTW we got some feedback that the deprecation message could be improved on this PR. Here is a proposal: |
Which issue does this PR close?
Closes #13968 .
Rationale for this change
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?