[SERVER-63518] Equivalent find and agg queries produce different plans and different results from a decimal field Created: 10/Feb/22 Updated: 06/Dec/22 Resolved: 10/Feb/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Query Execution |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Timour Katchaounov | Assignee: | Backlog - Query Execution |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: |
The plan of the aggregate query is:
The plan of the find query is:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 20 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
The following two equivalent queries produce a different result, and different plans. The aggregation query constant-folds the expression, and chooses an SBE plan, while the find query doesn't constant-fold, and produces a different result. The different results have been found by the fuzzer test from BF-23998.
The problem seems to be at few levels:
|
| Comments |
| Comment by Kyle Suarez [ 10/Feb/22 ] |
|
Closing as a duplicate of |
| Comment by Yoon Soo Kim [ 10/Feb/22 ] |
|
kyle.suarez, Yes, it is. For the find query, the query is not pushed down to the SBE probably because $pow is not compatible with the SBE (same for aggregate but I don't know why the pipeline can be pushed down and the find query can NOT be pushed down). So we use the classic engine's double double sum algorithm (ExpressionAdd::evaluate) which preserves 34 digits since the folded const double is added to nonDecimalTotal and at the final step, the nonDecimalTotal is promoted to a decimal with 34 digit rounding option. I don't think it's the constant folding to blame but it's the inconsistent behavior of genericArithmeticOp<Addition>() which promotes a double to a decimal with 15 digit rounding option. |
| Comment by Kyle Suarez [ 10/Feb/22 ] |
|
yoonsoo.kim, is this the same underlying cause as one of the other SBE Decimal tickets you've filed? |