-
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
Query: SQL group by when aggregate operators have complex expression #11976
Labels
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
customer-reported
type-enhancement
Milestone
Comments
Closed
Dependent on #12089 |
smitpatel
added
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
and removed
punted-for-3.0
labels
Jul 1, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
customer-reported
type-enhancement
Is client evaluated since the expression inside Sum is not member expression. That is our current logic to avoid issues with unmapped properties. In general we can relax the criteria but currently we decide in RequiresMaterialization if we can translate of not. At that point we cannot accurately know if we can translate it or not. (materialization tells client group by vs server group by). We can remove strict check and allow translation of more patterns but if something which cannot be translated is encountered then we fail.
As an effective fix for this (and other issue with joins #10012 ) we can pull the selector into GroupResultOperator (with custom operator) and we can make determination of group by during translation strictly.
The text was updated successfully, but these errors were encountered: