[SERVER-58443] Allow $near/$nearSphere on a view Created: 29/Jun/21 Updated: 09/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | David Percy | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | read-only-views | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Linked BF Score: | 163 | ||||||||||||||||||||||||||||
| Description |
|
In view resolution we need to translate all the parts of a .find() query into equivalent aggregation stages. Currently $near and $nearSphere aren't supported on views because syntactically they're part of the .find() predicate, which becomes a $match, but semantically they also sort the results, which $match can't. We should be able to translate any .find() predicate to a combination of $geoNear and $match stages. We'll need to make $geoNear's 'distanceField' argument optional. |
| Comments |
| Comment by David Percy [ 03/Feb/22 ] |
|
I had to revert this because it caused a performance regression with views. Currently when we translate find() on a view to an aggregate(), we don't have a parsed MatchExpression yet. We have FindCommandRequest which has BSON for each part of the query (filter, projection, sort, etc). To handle $near/$nearSphere we need to parse the predicate so we can split it up into a conjunction of $near/$nearSphere and everything else. For example, given find({name: "abc", loc: {$near: [0, 0]}, temp: {$lt 70}}), we need to split it up into {name: "abc", temp: {$lt: 70}} and {loc: {$near: [0, 0]}}. My plan was to use CanonicalQuery, because that also takes care of flattening nested $and. But this adds some work to all find() queries on views, which can be bad for very short queries. I believe any $near or $nearSphere query can be expressed as a $geoNear aggregation, so this feature would really be a syntax improvement. We could reopen if that's something people would find useful. |
| Comment by Githook User [ 19/Aug/21 ] |
|
Author: {'name': 'David Percy', 'email': 'david.percy@mongodb.com', 'username': 'dpercy'}Message: Revert "SERVER-58443 Translate $near/$nearSphere on a view to $geoNear" This reverts commit 02894677cc0eaa10fac99d2b99f18abf4fc33c74. |
| Comment by Githook User [ 19/Aug/21 ] |
|
Author: {'name': 'David Percy', 'email': 'david.percy@mongodb.com', 'username': 'dpercy'}Message: Revert "SERVER-58443 Translate $near/$nearSphere on a view to $geoNear" This reverts commit 65fec2e68f4ae57d2218290ee6744648a18a2ed4. |
| Comment by Githook User [ 11/Aug/21 ] |
|
Author: {'name': 'David Percy', 'email': 'david.percy@mongodb.com', 'username': 'dpercy'}Message: SERVER-58443 Translate $near/$nearSphere on a view to $geoNear |
| Comment by Githook User [ 11/Aug/21 ] |
|
Author: {'name': 'David Percy', 'email': 'david.percy@mongodb.com', 'username': 'dpercy'}Message: SERVER-58443 Translate $near/$nearSphere on a view to $geoNear |
| Comment by Githook User [ 19/Jul/21 ] |
|
Author: {'name': 'David Percy', 'email': 'david.percy@mongodb.com', 'username': 'dpercy'}Message: SERVER-58443 Make $geoNear distanceField optional |