-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PERF-5374 Improve comment headers for multiplanner/ workloads #1213
Changes from 21 commits
7d3550a
9ac18f3
727c8f5
3966b55
608dbb0
46a82aa
d813797
bb2a774
dc9b3af
70fd686
9953a7b
9948cf8
d691dd8
e12b6eb
2b0b7bb
c9d3933
d0b801d
69cbdc6
8524dec
d61a02b
e52494b
d5c7d76
1830416
42a536b
b5ba2ba
539fad1
324a0c3
e9a2b5e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -1,15 +1,11 @@ | ||||||
SchemaVersion: 2018-07-01 | ||||||
Owner: "@mongodb/query" | ||||||
Description: | | ||||||
The goal of this test is to exercise multiplanning. We create as many indexes as possible, and run a | ||||||
query that makes all of them eligible, so we get as many competing plans as possible. We add a | ||||||
group stage, which is blocking. The SBE multiplanner will multiplan group as it is a part of the | ||||||
canonical query, but the classic multiplanner will not plan. This means the SBE multiplanner will | ||||||
have the overhead of trial running blocking plans when compared to the classic multiplanner. | ||||||
|
||||||
We expect classic to have better latency and throughput than SBE on this workload, | ||||||
and we expect the combination of classic planner + SBE execution (PM-3591) to perform about | ||||||
as well as classic. | ||||||
This test was created to show how three different multiplanners handle $group. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
The query is essentially the one from 'Simple.yml': we have as many indexed predicates as | ||||||
possible, to create as many indexed plans as possible, but only one of those predicates is | ||||||
selective, which means only one of those plans is efficient. Where this test departs from | ||||||
dstorch marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
'Simple.yml' is by adding a $group stage after the access-path part of the query. | ||||||
|
||||||
GlobalDefaults: | ||||||
dbname: &db test | ||||||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,10 +6,6 @@ Description: | | |
are very selective (match 0% of the documents). With zero results, we do no hit the EOF optimization | ||
and all competing plans hit the works limit instead of document limit. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wait, reading this again I'm confused about the purpose of this workload. Won't every plan hit EOF immediately because the interval for the index scan is empty? If I'm reading things correctly, this note about not hitting the EOF optimization is wrong. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oops, you're right and we must have discussed this previously, because I had left the same comment on the google doc: https://docs.google.com/document/d/1hBJoIOwDMPZItTCvYTebfbACB62YwvhRCo7pP8Q_iy4/edit?disco=AAABM1bxvks There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If the goal were to hit max works, then a better test would be to have all the indexed predicates select 100% of documents, and have one residual predicate that selects 0%. This is what I'll just update the comment here to describe what this file actually does. |
||
|
||
We expect classic to have better latency and throughput than SBE on this workload, | ||
and we expect the combination of classic planner + SBE execution (PM-3591) to perform about | ||
as well as classic. | ||
|
||
GlobalDefaults: | ||
dbname: &db test | ||
# Collection name used for queries. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've fixed this description as part of #1224 which I merged this morning. So when you merge with the latest from master, I think this PR should end up in a state where it does not make any changes to this file. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right, after updating it looks like NoSuchField.yml is unchanged in this PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Except the linter complained so I had to add a "Keywords" section. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, why did the linter complain for this workload but not the others? In your branch, only two of the multiplanner workloads have the keyword specified. I guess you should either add |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[optional] We are still comparing the classic multi-planner to the SBE multi-planner here. Could consider cleaning that up.