[SERVER-5580] covered indexes are improperly applied when arrays do not have multiple values Created: 11/Apr/12 Updated: 25/Aug/23 Resolved: 27/Jan/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Aaron Staple | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||
| Sprint: | Query 2017-02-13 | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||
| Description |
|
Issue Status as of Aug 24, 2023 ISSUE DESCRIPTION AND IMPACT This patch, included in MongoDB 3.6, corrected covered query behavior by changing how empty and single-element arrays are treated with respect to multikey indexes:
However, this change did not address the index metadata of existing indexes built on MongoDB versions 3.4 and earlier. This means that existing indexes containing empty or single-element arrays (like [] or [1]) are not guaranteed to be marked as multikey and may still incorrectly be eligible for use by covered queries. Applications are unlikely to be affected because:
DIAGNOSIS AND AFFECTED VERSIONS When an index is affected by this change on MongoDB 3.6 or later, covered queries using those indexes still return scalar instead of array values (1 instead of [1]). If at any time the index receives an insert (including of an empty or single-element array), it becomes a multikey index and correct behavior becomes enforced. Until then, validate() reports the index as inconsistent because it detects the discrepancy between the following:
REMEDIATION AND WORKAROUNDS Data models that regularly use array data for the fields in affected indexes almost immediately "self-heal" the metadata inconsistency that this change allowed, as soon as a write occurs that would make the index multikey. For other cases, the remediation for this issue is to rebuild affected indexes. Original descriptionA multikey index is one with multiple distinct values for a field, and covered mode isn't used for multikey indexes. However, it is possible to have an array containing only one unique value and such arrays are currently handled incorrectly by the covered indexing implementation.
I believe there is a similar case where the array contains numbers that compare as equal but are of different data types. |
| Comments |
| Comment by Githook User [ 27/Jan/17 ] | |||
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: This is required in order for the planner to enforce correct | |||
| Comment by Asya Kamsky [ 28/Dec/16 ] | |||
|
The original example only shows the first behavior: when a:[1] is present the index is not multikey and it returns a:1 instead of a:[1] however as soon as a:[1,1] is added the index properly becomes multikey and indexed query does the right thing.
|