-
Notifications
You must be signed in to change notification settings - Fork 3.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
Redo our pruning implementation #31083
Labels
area-query
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-enhancement
Milestone
Comments
3 tasks
8 tasks
roji
added a commit
to roji/efcore
that referenced
this issue
Dec 25, 2023
roji
added a commit
to roji/efcore
that referenced
this issue
Dec 25, 2023
roji
added a commit
to roji/efcore
that referenced
this issue
Dec 25, 2023
Cloess dotnet#31083 Fixes dotnet#31407
roji
added a commit
to roji/efcore
that referenced
this issue
Dec 25, 2023
Closes dotnet#31083 Fixes dotnet#31407
Merged
roji
added a commit
to roji/efcore
that referenced
this issue
Dec 25, 2023
Closes dotnet#31083 Fixes dotnet#31407
roji
added a commit
that referenced
this issue
Dec 29, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area-query
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-enhancement
Our current pruning logic currently only operates on SelectExpressions which are present in the Tables list of other SelectExpressions; it notably doesn't handle subqueries embedded e.g. in the predicate.
For example, given the following entity type:
... and the following query:
... the Unneeded column gets properly pruned from the projection:
But if you place the same thing inside a subquery:
... that yields the following SQL, which does project Unneeded:
The reason for this is that the pruning logic isn't implemented as a proper visitor which visits the entire tree; instead, SelectExpressionPruningExpressionVisitor (in postprocessing) calls SelectExpression.Prune; this recurses into Tables, but not into the other parts of the query.
We should extract the pruning logic out to SelectExpressionPruningExpressionVisitor, taking care with SelectExpression private state etc. Note #31049 (comment) which is similar, abuot allowing providers to add other pruning logic.
The text was updated successfully, but these errors were encountered: