Skip to content
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

executor: do not reorder handles when building requests for IndexMergeJoin #20138

Merged
merged 5 commits into from
Sep 22, 2020

Conversation

qw4990
Copy link
Contributor

@qw4990 qw4990 commented Sep 22, 2020

What problem does this PR solve?

Issue Number: close #20137

Problem Summary: executor: do not reorder handles when building requests for IndexMergeJoin

What is changed and how it works?

Reordering handles when building requests is for merging successive handles into one, for example h in (2, 3, 1) can be merged to (h>=1 and h<=3), which may improve the performance.

But some handles may overflow, after reordering, they cannot keep the original order.

IndexMergeJoin requires all rows returned in a specific order, so reordering handles may break this.

To avoid this risk, do not reorder handles when building requests for IndexMergeJoin.

Check List

Tests

  • Unit test

Release note

  • executor: do not reorder handles when building requests for IndexMergeJoin

@qw4990 qw4990 added type/bugfix This PR fixes a bug. sig/execution SIG execution labels Sep 22, 2020
@qw4990 qw4990 requested a review from a team as a code owner September 22, 2020 03:45
@qw4990 qw4990 requested review from XuHuaiyu and removed request for a team September 22, 2020 03:45
Copy link
Contributor

@lzmhhh123 lzmhhh123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ti-srebot ti-srebot added the status/LGT1 Indicates that a PR has LGTM 1. label Sep 22, 2020
@XuHuaiyu
Copy link
Contributor

I don't know why some handles may overflow?

@XuHuaiyu
Copy link
Contributor

LGTM

@ti-srebot ti-srebot removed the status/LGT1 Indicates that a PR has LGTM 1. label Sep 22, 2020
@ti-srebot ti-srebot added the status/LGT2 Indicates that a PR has LGTM 2. label Sep 22, 2020
@qw4990 qw4990 added the status/can-merge Indicates a PR has been approved by a committer. label Sep 22, 2020
@ti-srebot
Copy link
Contributor

Your auto merge job has been accepted, waiting for:

  • 20142

@ti-srebot
Copy link
Contributor

/run-all-tests

@ti-srebot
Copy link
Contributor

@qw4990 merge failed.

@qw4990
Copy link
Contributor Author

qw4990 commented Sep 22, 2020

/merge

@ti-srebot
Copy link
Contributor

Your auto merge job has been accepted, waiting for:

  • 20142

@ti-srebot
Copy link
Contributor

/run-all-tests

@ti-srebot
Copy link
Contributor

@qw4990 merge failed.

@qw4990
Copy link
Contributor Author

qw4990 commented Sep 22, 2020

/run-all-tests

@qw4990 qw4990 merged commit 640cb42 into pingcap:master Sep 22, 2020
ti-srebot pushed a commit to ti-srebot/tidb that referenced this pull request Sep 22, 2020
Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
@ti-srebot
Copy link
Contributor

cherry pick to release-4.0 in PR #20147

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/execution SIG execution status/can-merge Indicates a PR has been approved by a committer. status/LGT2 Indicates that a PR has LGTM 2. type/bugfix This PR fixes a bug.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

unexpected results returned by IndexMergeJoin
4 participants