[SERVER-18957] Split ExpressionNary::isAssociativeAndCommutative() into separate properties Created: 12/Jun/15 Updated: 06/Dec/22 Resolved: 02/Feb/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework, Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.2 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Mathias Stearn | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | pull-request | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query
|
| Backwards Compatibility: | Fully Compatible |
| Participants: |
| Description |
|
Then we can apply the optimizations on expressions that are one but not the other. For example $concat is associative, but not commutative. |
| Comments |
| Comment by Githook User [ 02/Feb/16 ] |
|
Author: {u'username': u'salessandri', u'name': u'Santiago Alessandri', u'email': u'san.lt.ss@gmail.com'}Message: Closes #1024 Signed-off-by: Charlie Swanson <charlie.swanson@mongodb.com> |
| Comment by Charlie Swanson [ 07/Dec/15 ] |
|
geert.bosch it's too late for that. See |
| Comment by Geert Bosch [ 07/Dec/15 ] |
|
Just note that neither floating-point nor integer arithmetic is associative, so we should make sure not to start optimizing based on the assumption they are. |
| Comment by Santiago Alessandri [ 07/Dec/15 ] |
|
I updated the PR. I refactor the Nary optimization to take into account the possibility of having associative and not commutative expressions. |
| Comment by Ramon Fernandez Marina [ 29/Oct/15 ] |
|
Thanks for the pull request salessandri, we'll run it through internal testing and get back to you. |
| Comment by Santiago Alessandri [ 29/Oct/15 ] |
|
I started working on this issue. I made a PR to get the first feedback: https://github.com/mongodb/mongo/pull/1042 A couple of comments of what I did:
What I haven't done yet is:
|