[SERVER-34891] failIndexKeyTooLong should be a per-index option, not a system wide Created: 08/May/18 Updated: 06/Dec/22 Resolved: 18/May/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | 3.6.4 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Critical - P2 |
| Reporter: | William Byrne III | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Storage Execution
|
| Participants: | |
| Case: | (copied to CRM) |
| Description |
|
The failIndexKeyTooLong server parameter was introduced as a way to permit indexes created in version 2.4 or earlier to be migrated to version 2.6, despite them having documents with field values longer than 1024 bytes and indexes on those fields. The intention was that customers would clean up their data or change the index definitions so that the key field values for all documents were under the Index Key Limit of 1024 bytes, and return failIndexKeyTooLong to its default of true. This has not happened -there are still customers with failIndexKeyTooLong=false in version 3.4. Indexes created or updated while failIndexKeyTooLong=false ignore any documents where the total key field length exceeds the Index Key Limit. If there are documents with long keys that would match a particular query, plans that use an IXSCAN against those indexes silently return fewer documents than plans that use other indexes or collection scans. While failIndexKeyTooLong is a server wide parameter, any document insert or update into any collection could include an overlong key field, and the index(es) on that collection would potentially return incomplete results for queries that should have included the document with the long key. If we change failIndexKeyTooLong to be an option passed to createIndex() and visible in getIndexes() output, then database users will know that queries using that index might not return all the qualifying documents, and can force use of a different plan if they desire. |
| Comments |
| Comment by Ian Whalen (Inactive) [ 18/May/18 ] |
|
Resolving as Won't Fix since we plan to remove the indexed key length limit in 4.2. |
| Comment by Asya Kamsky [ 13/May/18 ] |
|
It's not clear to me what pain this is trying to solve (I understand the proposed solution, but I don't see what it's trying to address). In any case, I think the correct solution is either to allow longer index keys, or forbid them, not the current in-between state.
|