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

Enhance access path selection #8593

Closed
alivxxx opened this issue Dec 6, 2018 · 4 comments
Closed

Enhance access path selection #8593

alivxxx opened this issue Dec 6, 2018 · 4 comments
Labels
sig/planner SIG: Planner type/enhancement The issue or PR belongs to an enhancement.

Comments

@alivxxx
Copy link
Contributor

alivxxx commented Dec 6, 2018

Feature Request

Is your feature request related to a problem? Please describe:

Suppose there is a table:
create table t(a int, b int, c int, index idx1(b, a), index idx2(a));;
For queries like select * from t where a = x and b = xx, the optimizer may choose idx2, but it is a very risky path compares to idx1.

Describe the feature you'd like:

If there are multi paths available, and the access conditions of the path a could strictly covers b, then we should never choose b as access condition.

@alivxxx alivxxx added type/enhancement The issue or PR belongs to an enhancement. sig/planner SIG: Planner labels Dec 6, 2018
@eurekaka
Copy link
Contributor

eurekaka commented Dec 6, 2018

Seems it already works now?

mysql> create table t(a int, b int, c int, index idx1(b, a), index idx2(a));
Query OK, 0 rows affected (0.01 sec)

mysql> explain select * from t where a = 1 and b = 1;
+-------------------+-------+------+----------------------------------------------------------------------+
| id                | count | task | operator info                                                        |
+-------------------+-------+------+----------------------------------------------------------------------+
| IndexLookUp_10    | 0.10  | root |                                                                      |
| ├─IndexScan_8     | 0.10  | cop  | table:t, index:b, a, range:[1 1,1 1], keep order:false, stats:pseudo |
| └─TableScan_9     | 0.10  | cop  | table:t, keep order:false, stats:pseudo                              |
+-------------------+-------+------+----------------------------------------------------------------------+
3 rows in set (0.00 sec)

You mean the stats may result in a wrong choice?

@alivxxx
Copy link
Contributor Author

alivxxx commented Dec 6, 2018

@eurekaka Yes, the stats may result in a wrong choice.

@shenli
Copy link
Member

shenli commented Dec 6, 2018

I guess there are many heuristic rules in other database's operators. Could we borrow something?

@alivxxx
Copy link
Contributor Author

alivxxx commented Dec 6, 2018

Yes, there are some other interesting rules like skyline pruning, we could learn from them.

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

No branches or pull requests

3 participants