-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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, executor: support index merge's order prop push down at the normal way #43881
planner, executor: support index merge's order prop push down at the normal way #43881
Conversation
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
9bf9fb5
to
5f8dc44
Compare
planner/core/find_best_task.go
Outdated
// Add sort items for index scan for merge-sort operation between partitions. | ||
byItems := make([]*util.ByItems, 0, len(prop.SortItems)) | ||
for _, si := range prop.SortItems { | ||
byItems = append(byItems, &util.ByItems{ | ||
Expr: si.Col, | ||
Desc: si.Desc, | ||
}) | ||
} | ||
ts.ByItems = byItems |
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.
Looks like we can pass []*util.ByItems
to this function to reduce the repeated code here and in convertToPartialIndexScan
.
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.
PTAL again. The byItems
for each partial plan are the same.
Do we need to build new byItems
for each of them? It looks like sharing the same one is enough.
@@ -348,10 +349,9 @@ func (e *IndexMergeReaderExecutor) startPartialIndexWorker(ctx context.Context, | |||
memTracker: e.memTracker, | |||
partitionTableMode: e.partitionTableMode, | |||
prunedPartitions: e.prunedPartitions, | |||
byItems: e.byItems, |
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.
Looks like we don't need to change here.
Because we will set this in PhysicalIndexMergeReader.ByItems
(Init()
) then IndexMergeReaderExecutor.byItems
(buildNoRangeIndexMergeReader
), so finally they are the same.
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.
Yeah, I want to do the remained part in the later pull.
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.
UnionScan with IndexMerge also have problems both for normal table and parititon table. We should also fixed it in this PR.
mysql> create table t(a int, b int, c int, key idx(a, c), key idx1(b, c));
Query OK, 0 rows affected (0.02 sec)
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into t(a, b, c) values (6,6,6),(3,3,3),(9,9,9),(4,4,4),(5,5,5),(7,7,7),(8,8,8);
Query OK, 7 rows affected (0.00 sec)
Records: 7 Duplicates: 0 Warnings: 0
mysql> select * from t where a = 6 or b = 3 order by c limit 10;
+------+------+------+
| a | b | c |
+------+------+------+
| 6 | 6 | 6 |
| 3 | 3 | 3 |
+------+------+------+
2 rows in set (0.01 sec)
Like #45140, and sort result in indexMerge.MemTableReader
This pr can be closed since #45140 is published. |
The wrong pull is linked. This pull should be reopened |
d3f011a
to
5829795
Compare
ab0c632
to
25dd692
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #43881 +/- ##
================================================
+ Coverage 73.1995% 73.2136% +0.0141%
================================================
Files 1265 1268 +3
Lines 390142 390811 +669
================================================
+ Hits 285582 286127 +545
- Misses 86243 86336 +93
- Partials 18317 18348 +31
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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.
reset is good since 25dd692d12c04b81fed5514df4d1227ebbebd1a4
25dd692
to
2c3c27c
Compare
@@ -935,6 +935,54 @@ func (p *PhysicalLimit) sinkIntoIndexLookUp(t task) bool { | |||
return true | |||
} | |||
|
|||
func (p *PhysicalLimit) sinkIntoIndexMerge(t task) bool { |
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.
I notice that this function is quite similar to sinkIntoIndexLookUp
. Can we merge them into one function?
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.
There's some type assertion in the codes. It might introduce more code complexity for the pull. We can left it for next pulls. Such as add a new common interface for the two struct.
planner/core/find_best_task.go
Outdated
// Add sort items for index scan for merge-sort operation between partitions. | ||
byItems := make([]*util.ByItems, 0, len(prop.SortItems)) | ||
for _, si := range prop.SortItems { | ||
byItems = append(byItems, &util.ByItems{ | ||
Expr: si.Col, | ||
Desc: si.Desc, | ||
}) | ||
} | ||
ts.ByItems = byItems |
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.
PTAL again. The byItems
for each partial plan are the same.
Do we need to build new byItems
for each of them? It looks like sharing the same one is enough.
Co-authored-by: Hangjie Mo <mohangjie1995@gmail.com> Co-authored-by: Zhou Kunqin <25057648+time-and-fate@users.noreply.github.com>
@winoros: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Defined2014, time-and-fate The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
[LGTM Timeline notifier]Timeline:
|
What problem does this PR solve?
Issue Number: ref #41028, close #43577, close #45387
Problem Summary:
Previously, we used a hack to support the order prop push-down for index merge.
What is changed and how it works?
We put the order prop checking at the regular physical property checking. Making it correct for the optimizer to be notified that the order prop is pushed down.
Check List
Tests
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.