[SERVER-39708] Fastpath no-ops to multikey updates in IndexBuildInterceptor::sideWrite to avoid mutex acquisition Created: 21/Feb/19  Updated: 29/Oct/23  Resolved: 11/Sep/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.2.1, 4.3.1

Type: Improvement Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Maria van Keulen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.2
Sprint: Execution Team 2019-07-29, Execution Team 2019-09-09, Execution Team 2019-09-23
Participants:

 Description   

The hybrid index build's IndexBuildInterceptor accumulates multikey changes in memory which is used to update the persisted index metadata once at the end of the index build.

Every document inserted into the "side table" will grab a mutex to update this in-memory multikey paths variable. In the common case where a document is not multikey, this shared state does not need to be modified (multikey is similar to a set that can only be added to).

The serialization was done out of convenience. There's only one exposed helper method for working with MultikeyPaths "objects". Specifically, the following two methods would allow only grabbing the mutex when a document is multikey w.r.t. an index:

  1. Instantiating the default/"empty" multikey object for a given index spec.
  2. A predicate that says whether a MultikeyPaths is equal to the default/"empty".

Given (1), the _multikeyPaths can be initialized to the correct "shape" at IndexBuildInterceptor construction time. This clause can be removed.
Given (2) merging would only need to happen if the document could potentially change multikey state.

UPDATE: This optimization was only made for BTree indexes because all other index types either do not track path-level multikey information or have "special" handling of multikey paths.



 Comments   
Comment by Githook User [ 13/Sep/19 ]

Author:

{'name': 'Maria van Keulen', 'username': 'mvankeulen94', 'email': 'maria.vankeulen@mongodb.com'}

Message: SERVER-39708 Optimize Btree multikey updates

(cherry picked from commit bfac8d909877600c395dccc575effbfbae76a82a)
Branch: v4.2
https://github.com/mongodb/mongo/commit/ade1c1f91effa7b86aa8b82daa8548d360b2bc68

Comment by Githook User [ 10/Sep/19 ]

Author:

{'name': 'Maria van Keulen', 'username': 'mvankeulen94', 'email': 'maria.vankeulen@mongodb.com'}

Message: SERVER-39708 Optimize Btree multikey updates
Branch: master
https://github.com/mongodb/mongo/commit/bfac8d909877600c395dccc575effbfbae76a82a

Comment by Eric Milkie [ 31/Jul/19 ]

I put this ticket on hold and moved it for consideration again in the next QW bucket.

Comment by Maria van Keulen [ 31/Jul/19 ]

I ran into another hiccup when excluding text and wildcard indexes from these checks. These tests fail as of my changes, because they rely on multikeyPaths being equal to boost::none to indicate that the index should not be marked as multikey. We cannot make assumptions regarding whether wildcard indexes are multikey, so we cannot rely on checking the type of the index to substitute checking equality against boost::none in the code. Some further consideration is necessary for this work, so I believe this ticket should be revisited at a later time. CC milkie

Comment by Maria van Keulen [ 30/Jul/19 ]

There are some wrinkles with this work because of wildcard and text indexes. Presently in the code, both of these indexes can end up with empty MultikeyPaths passed to sideWrite, but still be marked as multiKey . It seems like marking text indexes as multikey is unexpected behavior. It seems like wildcard indexes have their own means of tracking multikey paths, which is separate from the code paths that update _multikeyPaths.
I will investigate whether there is a straightforward way to exclude these two index types from this work, and if so, file a ticket for follow-up work to address these two indexes.

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