Skip to content
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

Update API for extension planning to include logical plan #643

Merged
merged 2 commits into from
Jul 1, 2021

Conversation

alamb
Copy link
Contributor

@alamb alamb commented Jun 29, 2021

Which issue does this PR close?

Closes #642

Rationale for this change

With the introduction of qualified identifiers in #55 I am having trouble creating plans with user defined nodes because the extension traits don't have sufficient information about the logical plan to create the correct PhysicalExprs.

#642 describes in more detail what is going on

What changes are included in this PR?

  1. Add a PhysicalPlanner::create_physical_expr to the planer trait
  2. Change the signature of ExtensionPlanner::plan_extension to include a reference to the planner as well as the logical inputs

Are there any user-facing changes?

Yes: Extension API and PhysicalPlanner interfaces have changed

@alamb alamb added the api change Changes the API exposed to users of the crate label Jun 29, 2021
@github-actions github-actions bot added the datafusion Changes in the datafusion crate label Jun 29, 2021
/// This errors when the planner knows how to plan the concrete implementation of `node`
/// but errors while doing so, and `None` when the planner does not know how to plan the `node`
/// and wants to delegate the planning to another [`ExtensionPlanner`].
///
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The challenge prior to this PR is if the extension node has any Exprs to convert them into PhysicalExprs requires access to the LogicalPlan

Furthermore, there was no way to call back into create_physical_expr from the ExtensionPlanner so I added that to the trait as well

@alamb
Copy link
Contributor Author

alamb commented Jun 30, 2021

Thank you for the review @houqp.

Any thoughts @andygrove / @Dandandan / @jorgecarleitao ? Otherwise I would like to merge this in the next day or so.

Copy link
Member

@jorgecarleitao jorgecarleitao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeap, clear for me. Great simplification and also some nice doc strings 👍

/// `input_schema`: the physical schema for evaluating `e`
fn create_physical_expr(
&self,
e: &Expr,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: why call it e? I think expr as variable name is more consistent with the whole codebase?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree expr is more consistent -- I think I was following the model of DefaultPhysicalPlanner::create_physical_expr. I will change

input_schema: &Schema,
ctx_state: &ExecutionContextState,
) -> Result<Arc<dyn PhysicalExpr>> {
self.create_physical_expr(e, input_dfschema, input_schema, ctx_state)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From here it looks like infinite recursion, but I might be wrong?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It somehow knows to call DefaultPhysicalPlanner::create_physical_expr -- I will make this clear

@alamb alamb merged commit 03cfcb2 into apache:master Jul 1, 2021
@alamb alamb deleted the alamb/extension_planning branch October 6, 2022 18:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api change Changes the API exposed to users of the crate datafusion Changes in the datafusion crate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow extension nodes to correctly plan physical expressions with relations
4 participants