-
Notifications
You must be signed in to change notification settings - Fork 14
File name and folder restructure #124
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
898fbf0 to
c01c11c
Compare
8d7ba36 to
355da32
Compare
NGA-TRAN
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.
Nice refactor and rename.
| mod tests { | ||
| use crate::assert_snapshot; | ||
| use crate::physical_optimizer::DistributedPhysicalOptimizerRule; | ||
| use crate::distributed_physical_optimizer_rule::DistributedPhysicalOptimizerRule; |
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 like you rename it to distributed_physical_optimizer_rule. Make it clearer
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.
yeah, I've tried to rename files to be a bit more consistent with the content.
| ) -> Result<Arc<dyn ExecutionPlan>> { | ||
| // We can only optimize plans that are not already distributed | ||
| if plan.as_any().is::<ExecutionStage>() { | ||
| if plan.as_any().is::<StageExec>() { |
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.
StageExec makes it more like DF style 👍
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.
Yeah, it seems like an unwritten rule to suffix all ExecutionPlan implementations with *Exec
| // Helper to create a mock physical plan | ||
| fn create_mock_physical_plan(partitions: usize) -> Arc<dyn ExecutionPlan> { | ||
| let node = Arc::new(EmptyExec::new(SchemaRef::new(Schema::empty()))); | ||
| Arc::new(RepartitionExec::try_new(node, Partitioning::RoundRobinBatch(partitions)).unwrap()) |
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 isn’t directly related to this PR, but might be something we consider updating or adding in a follow-up.
This RoundRobinBatch got me thinking 🤔. On one hand, it's a valid scenario we want our tests to cover. On the other, round-robin repartitioning isn’t ideal from a performance standpoint. How about we introduce a variety of partitioning schemes in our mock tests? That way, we can surface more realistic and appropriate cases while still including edge scenarios like this one.
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.
Yeah, we should do something with RoundRobin repartitions...
We probably should extend our parquet files test datasets so that we can cover more cases and more esoteric distribution patterns.
For example, it would be nice to have two test parquet files with related data that we can use to stress joins in weird ways.
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.
Probably something to follow up soon
This PR provides a better organization for the project colocating into modules the different pieces based on the features they are providing.
The new folder structure, as it colocates things related to each other more efficiently, allows to tweak the privacy of some structs/methods so that they are not expose to outside unrelated modules, and therefore reducing the chances of future coupling.
All the code is mostly untouched, only a couple of code changes are shipped for making this possible:
ExecutionTasknow has two forms:ExecutionTask: struct with theUrlalready parsed and the partition groups already asusizes, so that we don't need to do juggling in the code for parsing Urls or casing u64s to usizesExecutionTaskProto: the protobuf representation, decoupled from the actual useful structdo_getmethod was using directly the proto representation of theExecutionStageand theExecutionTask, but they are no longer exposed to the outside, so instead the normal structs are used, which then are converted to protos with theproto_to_stagefunction. This actually results in a nice cleanup that saves some lines of code.