-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
ALL
-
QO 2021-09-06, QO 2021-09-20, QO 2021-10-04, QO 2021-10-18, QO 2021-11-01, QO 2021-11-15, QO 2021-11-29
$geoNear sorts documents by their distance from a given query point. But its implementation is very tied to a particular index-scan plan, so it can only appear as the first stage in a pipeline.
We can lift this restriction by splitting it up into separate stages. Using the new internal-only stage from SERVER-58745, we could rewrite it like this:
{$geoNear: {
key: <fieldname>,
near: <point>,
minDistance: <min>,
maxDistance: <max>,
}}
=>
{$match: { <fieldname>: {$geoWithin: {$centerSphere: [<point>, <max>]}} }}
{$match: { <fieldname>: {$not: {$geoWithin: {$centerSphere: [<point>, <min>]}}} }}
{$_internalGeoNearDistance: {
key: <fieldname>,
near: <point>,
}}
{$sort: {$meta: 'geoNearDistance'}}
Splitting it up this way will allow other rewrites to optimize the $geoWithin and $sort.
- depends on
-
SERVER-59171 Allow {$meta: 'geoNearDistance'} syntax, at least internally
- Closed
-
SERVER-55239 Support 2dsphere index on time-series collection metadata fields
- Closed
-
SERVER-58745 Expose computeGeoNearDistance() as an internal-only DocumentSource
- Closed
- is depended on by
-
SERVER-61323 Optimize $geoNear minDistance bounds on time-series metrics
- Closed
- is duplicated by
-
SERVER-61323 Optimize $geoNear minDistance bounds on time-series metrics
- Closed
- is related to
-
SERVER-84974 Investigate $geoNear blocking sort
- Closed
- related to
-
SERVER-93613 Investigate if we should remove support for sorting by {$meta: "geoNearDistance"}
- Backlog