[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:

 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.

 

Generated at Thu Feb 08 04:38:11 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.