-
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
Refactor EnforceDistribution test cases to demonstrate dependencies across optimizer runs. #61
Conversation
bf5a9a1
to
498983f
Compare
/// Perform a series of runs using the current [`TestConfig`], | ||
/// assert the expected plan result, | ||
/// and return the result plan (for potentional subsequent runs). | ||
fn run( | ||
&self, | ||
expected_lines: &[&str], | ||
plan: Arc<dyn ExecutionPlan>, | ||
optimizers_to_run: Vec<Run>, | ||
) -> Result<Arc<dyn ExecutionPlan>> { | ||
let expected_lines: Vec<&str> = expected_lines.to_vec(); |
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.
The reason this returns the plan, is so that we can easily write test cases for idempotency.
let plan_after_first_run = test_config.run(
expected,
plan,
vec![Run::Distribution],
)?;
let plan_after_second_run = test_config.run(
expected,
plan_after_first_run.clone(),
vec![Run::Distribution], // exact same run again
)?;
assert_eq!(
get_plan_string(&plan_after_first_run),
get_plan_string(&plan_after_second_run),
);
const DISTRIB_DISTRIB_SORT: [Run; 3] = | ||
[Run::Distribution, Run::Distribution, Run::Sorting]; |
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.
const SORT_DISTRIB_DISTRIB: [Run; 3] = | ||
[Run::Sorting, Run::Distribution, Run::Distribution]; |
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.
// TODO(wiedld): show different test result if enforce distribution first. | ||
test_config.run( | ||
&expected_first_sort_enforcement, | ||
top_join, | ||
&TestConfig::new(DoFirst::Sorting).with_prefer_existing_sort() | ||
); | ||
SORT_DISTRIB_DISTRIB.into(), | ||
)?; |
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 left a few TODO(wiedld)
in the test multi_smj_joins.
In some cases the test case is showing the outcome for the sort occurring first BEFORE the distribution run, which does not match the ordering of the optimizer in the default planner -- and I thought that should be highlighted in the test cases.
|
||
// Test: result IS DIFFERENT, if EnforceSorting is run first: |
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.
Highlighting the dependency of run ordering in the existing test cases.
…and highlight when the same testing setup, but different ordering of optimizer runs, effect the outcome.
498983f
to
9411528
Compare
Closing this draft, since we opened a new one on the actual apache project. |
Which issue does this PR close?
Part of apache#15003
Is the next PR, after this previous PR merges: apache#15010
Rationale for this change
Enable us to write test cases using:
TestConfig
The benefits of this approach are:
What changes are included in this PR?
The above, as we as a bit of an increase in test coverage to demonstrate exactly when our test cases (the plan results we see) are ordering dependent.
Are these changes tested?
Yes
Are there any user-facing changes?
No