-
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 PhysicalPlanner
to physical_planer
module
#6570
Conversation
physical_planer
modulePhysicalPlanner
to physical_planer
module
3d73f4c
to
f004a97
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.
Make sense to me 👍
btw: its own crate to improve modularity and compile times
How to improve the compile times ? increase the degree of parallelism 🤔
Yes that is basically the hope/plan |
So |
I think initially it will be in the We could potentially move it to its own crate in the future too (though given it is not that much code, I don't know how valuable that would be) The issue is that the planner instantiates a bunch of things defined in The key issue in extracting Since the physical planner depends on Once I have |
Which issue does this PR close?
Part of #1754 (see #1754 (comment))
Rationale for this change
I am trying to extract
physical_plan
into its own crate to improve modularity and compile timesI am also trying to make sure the organization of the DataFusion crate is easier to understand for beginners.
What changes are included in this PR?
Move
PhysicalPlanner
and related structures tophysical_planner
moduleAre these changes tested?
Existing tests
Are there any user-facing changes?
Yes, documentation is improved (the planner is no longer buried in a sub module). Also, if users used the PhysicalPlanner directly they will need to update their
use
path