PERF-5373 Fix NoSuchField.yml so that it hits 'max works' as intended #1224
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Nice catch! |
mbor-dev
approved these changes
Jun 4, 2024
dpercy
approved these changes
Jun 4, 2024
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 5, 2024
**Jira Ticket:** [PERF-5375](https://jira.mongodb.org/browse/PERF-5375) ### Whats Changed I've opted to delete the workload because it seems redundant with NoSuchField.yml, which I'm improving in related PR #1224. The scenarios are slightly different because in NoSuchField.yml the extra predicate matches nothing, whereas in this case the extra predicate does match some data but cannot be answered efficiently. Still, the rationale for testing both of these cases is more or less the same so they seem redundant. I did consider applying the improvements originally described by this ticket to NoSuchField.yml -- namely, the idea of increasing the data size so that the "max works" value gets set based `0.3 * collectionSize`. I ultimately decided against doing so because it makes the workload take a lot longer to run. Just generating the data set and building the indexes took a few minutes, and a single invocation of the query with 64 indexes took over 2 minutes. It seems more important to me to allow the workload to run a few minutes total rather than covering the case where max works exceeds 10,000. ### Patch Testing Results As far as I know, just the automatically executed genny self-tests should be sufficient.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Jira Ticket: PERF-5373
Whats Changed
I confirmed that as originally implemented, the multi-planning trial period would end after the plan using index
{x1: 1}hit EOF. By changing this predicate from{x: {$lt: *selectivity}}to{x1: { $lte: 1}}, I've made it so that all of the indexed plans need to perform a large index scan. After this change, I've confirmed that none of the plans will hit EOF, and the trial period will instead terminate by hitting the "max works" condition.In addition, I noticed that we were unnecessarily repeating the
collModcommand to hide indexes 1000 times, so I fixed this to just hide indexes once.Patch Testing Results
I've confirmed that this lints locally by running
./run-genny -v lint-yaml --format.Kicked off a patch build: https://spruce.mongodb.com/version/6658beef88b0fc0007615e39/tasks. As of this writing, I'm letting it auto-generate tasks first and will need to come back and schedule the generated Genny task for this workload later.