-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
planner: increase default concurrency factor of cost computing #11752
Conversation
Codecov Report
@@ Coverage Diff @@
## master #11752 +/- ##
===============================================
- Coverage 81.776% 81.5477% -0.2284%
===============================================
Files 434 433 -1
Lines 94107 93506 -601
===============================================
- Hits 76957 76252 -705
- Misses 11684 11838 +154
+ Partials 5466 5416 -50 |
/run-all-tests |
@@ -23,24 +23,3 @@ id count task operator info | |||
IndexReader_11 1104.45 root index:Selection_10 | |||
└─Selection_10 1104.45 cop lt(test.access_path_selection.b, 3) | |||
└─IndexScan_9 3323.33 cop table:access_path_selection, index:a, b, range:[-inf,3), keep order:false, stats:pseudo | |||
CREATE TABLE `outdated_statistics` ( |
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.
Why remove it?
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.
Because this case is intended to test that planner would prefer idx_ab over idx_a, but it is hard to say whether double read using idx_ab is better than table scan or not. With the new concurrency factor, planner would prefer table scan, because there are only 6 rows in total.
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.
LGTM.
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.
LGTM
/run-all-tests |
What problem does this PR solve?
#10581 incurs 2.19% performance regression of oltp_read_write workload, this PR resolves this regression.
What is changed and how it works?
The performance regression is caused by the fact that: oltp_read_write contains a class of aggregation quires without Group By, the new cost model would prefer HashAgg which would run in parallel, while the old cost model prefers single-threaded StreamAgg. According to the actual benchmark, single-threaded StreamAgg is a little bit faster than multi-threaded HashAgg for this kind of query.
This PR adjust default concurrency factor to make planner prefer StreamAgg for this kind of query.
Check List
Tests
Code changes
N/A
Side effects
N/A
Related changes
N/A