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