|
The query system relies on the multikey flag to prohibit certain optimizations when scanning indexes that would result in "actually incorrect" results. One example is from index_bounds_builder.cpp:
// If the index is multikey, it doesn't matter what the tightness of the child is, we must
|
// return INEXACT_FETCH. Consider a multikey index on 'a' with document {a: [1, 2, 3]} and
|
// query {a: {$ne: 3}}. If we treated the bounds [MinKey, 3), (3, MaxKey] as exact, then we
|
// would erroneously return the document!
|
|
|
Moving this work from "3.3 Required" to "Planning Bucket A", since the user impact of unexpected transitions to multikey is small and there are some tricky technical obstacles. Specifically, the technical obstacles are:
- A multi-update can cause a transition to multikey, thereby killing itself. We would have to create a special mechanism to prevent the multi-update plan itself from getting killed, rather than simply using Collection::invalidateAll() to kill all queries currently active in the collection.
- Index catalog level operations (e.g. index drops) are currently the only callers of Collection::invalidateAll(), and these operations fail with a user assertion if there is an in-progress background index build. This is because Collection::invalidateAll() would kill the collection scan used to implement the background index build. It is not trivial to allow transitions to multikey to safely occur during a background index build, but it also is not ok for an update or insert operation to fail simply because it caused a multikeyness transition during a background index build.
CC milkie
|