You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During upgrade, downstream systems often experience issues due to implicit changes (not explicit API changes) of LogicalPlans that DataFusion code begins relying on, and which result in unintended consequences when upgrading to a new version of DataFusion (see #13525).
Describe the solution you'd like
The idea is to make the current implicit assumptions ("Invariants" in more formal language)( explict and automatically check them.
Explore possible API for user-defined invariants, and potential use cases with user-defined plan elements (e.g. physical plan nodes, analyzer and optimizer rules, etc). Refer to conversation here.
Consider options (e.g. generate of docs) to align the published docs with the invariants encoded.
What else should be included as a responsibility/check? Maintain input ordering if required?
(The idea is to have a check, perhaps run in debug mode, that would error if a user-defined physical plan or optimization pass fails to maintain the invariant. Throw error closer to the source when debugging.)
My impression was that the plan construction occurred with the LP (as we do), and not by constructing their own de novo physical plan. Is this correct?
If so, then I think the above list of invariants to check would most likely occur at the LP-level (not the physical plan). I can definitely put up a PR for those. Thank you!
Whereas for the physical plan invariants, (not LP), do we want any invariant checking there? Because I looked at the apache docs & physical plan APIs and from (my naive) understanding these are the only two invariants to check after physical plan mutations (a.k.a. PhysicalOptimizerRule applied). Is this correct? 🤔
My impression was that the plan construction occurred with the LP (as we do), and not by constructing their own de novo physical plan. Is this correct?
I am sorry -- I don't understand what you are asking (is LP LogicalPlan?) What does a de novo physical plan mean? You mean like creating a ExecutionPlan directly (not from a LogicalPlan)?
If so, then I think the above list of invariants to check would most likely occur at the LP-level (not the physical plan). I can definitely put up a PR for those. Thank you!
Whereas for the physical plan invariants, (not LP), do we want any invariant checking there? Because I looked at the apache docs & physical plan APIs and from (my naive) understanding these are the only two invariants to check after physical plan mutations (a.k.a. PhysicalOptimizerRule applied). Is this correct? 🤔
I am not sure what the actual invariants are (part of this project I think is to discover that information)
In my opinion we should be seeking to discover what the existing implicit assumptions are and encode them explicitly in the invariant check. Once we have all the existing assumptions encoded then we can move on to trying to add more assumptions
Activity
wiedld commentedon Dec 5, 2024
take
wiedld commentedon Dec 18, 2024
Possible tasks
wiedld commentedon Dec 26, 2024
For the physical optimization invariants, we have that the output physical plan schema cannot change; meaning the output results cannot change, but how we get the results can.
What else should be included as a responsibility/check? Maintain input ordering if required?
(The idea is to have a check, perhaps run in debug mode, that would error if a user-defined physical plan or optimization pass fails to maintain the invariant. Throw error closer to the source when debugging.)
alamb commentedon Dec 26, 2024
Here are some ideas based on bugs we have hit / my memory of what has changed and caused us pain:
wiedld commentedon Dec 27, 2024
My impression was that the plan construction occurred with the LP (as we do), and not by constructing their own de novo physical plan. Is this correct?
If so, then I think the above list of invariants to check would most likely occur at the LP-level (not the physical plan). I can definitely put up a PR for those. Thank you!
Whereas for the physical plan invariants, (not LP), do we want any invariant checking there? Because I looked at the apache docs & physical plan APIs and from (my naive) understanding these are the only two invariants to check after physical plan mutations (a.k.a. PhysicalOptimizerRule applied). Is this correct? 🤔
alamb commentedon Dec 28, 2024
I am sorry -- I don't understand what you are asking (is LP LogicalPlan?) What does a de novo physical plan mean? You mean like creating a
ExecutionPlandirectly (not from aLogicalPlan)?I am not sure what the actual invariants are (part of this project I think is to discover that information)
In my opinion we should be seeking to discover what the existing implicit assumptions are and encode them explicitly in the invariant check. Once we have all the existing assumptions encoded then we can move on to trying to add more assumptions
alamb commentedon Jan 6, 2025
I just discovered that @houqp basically filed this same ticket 2 years ago:
alamb commentedon Jan 6, 2025
I suggest we use this ticket to track the infrastructure for checking invariants (e.g. what @wiedld is doing in #13986) and then claim success.
We can introduce additional invariant checks as we discover them as their own issues / mini projects
wiedld commentedon Jan 6, 2025
Agreed. Modifying this list above, we have infrastructure components of:
alamb commentedon Feb 6, 2025
Task complete!