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

Index merge doesn't take effect when using prefix key #16407

Closed
lilinghai opened this issue Apr 15, 2020 · 5 comments · Fixed by #20425
Closed

Index merge doesn't take effect when using prefix key #16407

lilinghai opened this issue Apr 15, 2020 · 5 comments · Fixed by #20425
Assignees
Labels
sig/planner SIG: Planner type/enhancement The issue or PR belongs to an enhancement.

Comments

@lilinghai
Copy link
Contributor

lilinghai commented Apr 15, 2020

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. What did you do?

create table t(a int,b char(100),key(a),key(b(10));
desc select /*+ use_index_merge(t) */ * from t where a=10 or b="x";

2. What did you expect to see?

use_index_merge takes effect

3. What did you see instead?

+-------------------------+----------+-----------+---------------+-------------------------------------+
| id                      | estRows  | task      | access object | operator info                       |
+-------------------------+----------+-----------+---------------+-------------------------------------+
| TableReader_7           | 8000.00  | root      |               | data:Selection_6                    |
| └─Selection_6           | 8000.00  | cop[tikv] |               | or(eq(d1.t.a, 10), eq(d1.t.b, "x")) |
|   └─TableFullScan_5     | 10000.00 | cop[tikv] | table:t       | keep order:false, stats:pseudo      |
+-------------------------+----------+-----------+---------------+-------------------------------------+
3 rows in set, 1 warning (0.01 sec)

4. What version of TiDB are you using? (tidb-server -V or run select tidb_version(); on TiDB)

Release Version: v4.0.0-rc-33-gd69868961
Git Commit Hash: d698689
Git Branch: release-4.0
UTC Build Time: 2020-04-15 02:59:00
GoVersion: go1.13.8
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false

@lilinghai lilinghai added the type/bug The issue is confirmed as a bug. label Apr 15, 2020
@zz-jason
Copy link
Member

@lzmhhh123 PTAL

@zz-jason zz-jason added type/enhancement The issue or PR belongs to an enhancement. and removed type/bug The issue is confirmed as a bug. labels Apr 15, 2020
@zz-jason zz-jason assigned lzmhhh123 and unassigned eurekaka Apr 15, 2020
@zz-jason zz-jason added the sig/planner SIG: Planner label Apr 15, 2020
@zz-jason zz-jason modified the milestone: v4.0.1 May 28, 2020
@qw4990
Copy link
Contributor

qw4990 commented Sep 21, 2020

@tangwz Do you willing to help us fix this?

@tangwz
Copy link
Contributor

tangwz commented Sep 21, 2020

@qw4990 I will give a try.

@tangwz
Copy link
Contributor

tangwz commented Sep 23, 2020

/assign

@lzmhhh123 lzmhhh123 removed their assignment Sep 29, 2020
@tangwz
Copy link
Contributor

tangwz commented Sep 30, 2020

I saw a comment in function accessPathsForConds(conditions []expression.Expression, usedIndexCount int):

// If AccessConds is empty or tableFilter is not empty, we ignore the access path.
// Now these conditions are too strict.

I think for prefix key we need change these conditions especially the condition tableFilter is not empty.

Should I change that limit?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/planner SIG: Planner type/enhancement The issue or PR belongs to an enhancement.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants