[SERVER-41058] Add concurrency workload targeted at multikey index writes Created: 08/May/19  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: newgrad
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-57268 add multikey query to validate_multik... Closed
is related to SERVER-18476 In-progress queries may return incorr... Backlog
Assigned Teams:
Storage Execution
Participants:
Linked BF Score: 19

 Description   

multikey indexes have been a frequent cause of bugs in recent releases. Adding concurrency tests that set indexes to multikey more frequently would help weed out bugs here. Doing this concurrently with transactions would also potentially be helpful.



 Comments   
Comment by Judah Schvimer [ 14/May/19 ]

I think both are interesting, but I'm more interested on maintenance on insert, especially when it occurs in parallel.

Comment by Max Hirschhorn [ 13/May/19 ]

The indexed_insert_multikey.js FSM workload inserts an array value for the "x" field, which causes the index to become multikey. If we're interested in stressing the index becoming multikey, then we may be able to get away with having a new FSM workload which just repeatedly drops and re-creates an index.

My question would be whether we'd rather have a new FSM workload which "slowly" fills in all of the indexed paths as being multikey. That is to say, has we historically had issues around the maintenance of multikey information on insert, on index creation, or does it not matter?

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