-
Notifications
You must be signed in to change notification settings - Fork 0
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
test: Demonstrate EnforceDistribution and EnforceSorting behavior on the latest DF branch. #60
base: main
Are you sure you want to change the base?
Conversation
… output to our test case
/// Same starting plan as [`repartitions_for_aggregate_after_sorted_union`], but adds a projection | ||
/// as well between the union and aggregate. This change the outcome: | ||
/// | ||
/// * we still get repartitioning | ||
/// * we still get another sort added | ||
/// * we no longer get 2 additional sorts pushed down below the union, after the first run | ||
#[test] | ||
fn repartitions_for_aggregate_after_sorted_union_projection() -> Result<()> { |
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 no longer inserts the coalesce. Even after 2 runs of enforce distribution.
} | ||
|
||
#[tokio::test] | ||
async fn test_preserve_needed_coalesce() -> Result<()> { |
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.
But this bug still occurs. EnforceSorting can make an valid plan, become invalid.
// Demonstrate: plan changes are not idempotent. | ||
// | ||
// After the second run, the optimizer: | ||
// * replaces the SPM with a sort, and removes the sorts pushed down below the union. | ||
// * swaps the repartition vs SPM. | ||
let expected_after_second_run = &[ |
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.
Proof that it's not idempotent.
// Demonstrate: plan changes are not idempotent. | ||
// | ||
// After the second run, the optimizer: | ||
// * replaces the SPM with a sort. | ||
let expected_after_second_run = &[ |
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 believe this is proof that it's not idempotent? 🤔
Follow up to #58, which demonstrates:
In this PR, we tried to recreate on the latest apache main branch. It was found that:
Followups:
Upstream/apache fix is going to focus on the EnforceSorting bug.
Separately, going to make some of the test setup cleanups from the EnforceDistribution learnings.