LevelDB storage engine
(MDEV-3841)
|
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Technical task | Priority: | Minor |
| Reporter: | Elena Stepanova | Assignee: | Sergei Petrunia |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | upstream | ||
| Issue Links: |
|
||||
| Description |
|
Expected result (all 3 rows satisfy the first two conditions, the last big OR shouldn't matter):
EXPLAIN:
Test case:
|
| Comments |
| Comment by Sergei Petrunia [ 2013-01-24 ] |
|
optimizer_trace shows this plan is used: "chosen_range_access_summary": { , , { "type": "range_scan", "index": "c", "rows": 20, "ranges": [ "p <= c <= p", "u <= c <= u" ] } ] |
| Comment by Sergei Petrunia [ 2013-01-24 ] |
|
The query plan looks incorrect: the index_merge has a branch for c IN ( 'p', 'u' ) (1) but does not have anything for OR c IN ( 'h', 'l', 'gw' ) (2) which seems wrong, because the WHERE clause has form of "(1) OR (2) OR ...". It is likely that the problem is observable only on leveldb, because other storage engine return different range estimates and so the optimizer chooses different query plan. |
| Comment by Elena Stepanova [ 2013-02-06 ] |
|
Filed a bug report with a test case involving InnoDB: http://bugs.mysql.com/bug.php?id=68194 |
| Comment by Elena Stepanova [ 2013-02-06 ] |
|
The upstream bug is said to have been fixed in 5.6.11, so i'm decreasing the priority of this one, but leaving it open till merge with 5.6.11, for the reference. |
| Comment by Sergei Petrunia [ 2013-02-13 ] |
|
The index_merge problem is tracked as |