[MDEV-6454] Performance degradation (suboptimal execution plan) on a query with expected range access Created: 2014-07-17 Updated: 2021-11-24 Resolved: 2014-10-22 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Optimizer |
| Affects Version/s: | N/A |
| Fix Version/s: | 10.1.1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Elena Stepanova | Assignee: | Sergei Petrunia |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Description |
|
Observed on 10.0-mdev6384 development tree (10.0 with the patch for
Table:
(data dump is attached) 10.0
Execution:
10.0-mdev6384-----------
Execution:
The effect seems to be stable. Persistent statistics doesn't help. |
| Comments |
| Comment by Sergei Petrunia [ 2014-07-18 ] | |||||||||||||||||||||||||||||||||||||||||
|
range optimizer: PRIMARY cost.total_cost() = 29.204678297523568 "col_smallint_key" (gdb) p cost.total_cost() range optimizer picks range(col_smallint_key). best_access_path(): test_if_skip_sort_order(): test_if_cheaper_ordering(): checking key=0 (PRIMARY) // it produces the desired ordering get_range_limit_read_cost (keynr=0, rows_limit=9709 /* = table_rows */) ... quick_rows[0] = 139 back to test_if_skip_sort_order()... another call to test_if_skip_sort_order() ... and calls select->test_quick_select() again.. which again returns no quick cursory examination inside shows that get_mm_tree()=NULL. and then, we start a full index scan on key=PRIMARY. Need to figure what goes on in the range optimizer. | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-07-18 ] | |||||||||||||||||||||||||||||||||||||||||
|
Experimenting with the first call to range optimizer: if you call ) while if you call ) | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-07-18 ] | |||||||||||||||||||||||||||||||||||||||||
|
RE-writing the WHERE condition a bit:
with key_map= {PRIMARY} it returns NULL (which is correct, because onecan't infer anything for "non_sargable_cond OR cond(PRIMARY)". with key_map={all-keys} it returns and index_merge tree. The next AND-ed condition is:
will remain with TREE=NULL. | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-07-18 ] | |||||||||||||||||||||||||||||||||||||||||
|
Prototype fix (removes the problem but ugly) | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-07-18 ] | |||||||||||||||||||||||||||||||||||||||||
|
The prototype fix patch includes fix for revno: 4290 [merge] | |||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2014-07-19 ] | |||||||||||||||||||||||||||||||||||||||||
|
The test case below causes an assertion failure on revno 4290 + psergey-mdev6454-prototype1.diff:
| |||||||||||||||||||||||||||||||||||||||||
| Comment by Elena Stepanova [ 2014-07-19 ] | |||||||||||||||||||||||||||||||||||||||||
|
The following query still shows performance regression on 10.0 + revno 4290 + psergey-mdev6454-prototype1.diff:
psergey-mdev6454-prototype1.diff:
10.0:
Datadump is attached as mdev6384_regression_2.dump | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-07-19 ] | |||||||||||||||||||||||||||||||||||||||||
|
An idea for an alternative to psergey-mdev6454-prototype1.diff: | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-07-19 ] | |||||||||||||||||||||||||||||||||||||||||
|
Fix the crash ( psergey-mdev6454-fix-crash2.diff) | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-07-19 ] | |||||||||||||||||||||||||||||||||||||||||
|
Also discovered a (simple) problem with cost calculations in the prototype patch. Will fix. | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-07-20 ] | |||||||||||||||||||||||||||||||||||||||||
|
the problem is: get_range_limit_read_cost() has this condition
It is supposed to fire when there was a ref(const) which is equivalent to the quick select. Apparently quick_n_ranges==1 is a wrong condition. | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-07-24 ] | |||||||||||||||||||||||||||||||||||||||||
|
A patch that should fix all regression and crash issues: psergey-mdev6454-attempt3.diff . The patch is against 10.0 tree, revision 4290, knielsen@knielsen-hq.org-20140711100647-nf3rdaf5ep26pgty. | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-07-24 ] | |||||||||||||||||||||||||||||||||||||||||
|
elenst, could you please make another test run with psergey-mdev6454-attempt3.diff? I'm interested in both performance regressions and crashes. | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-08-27 ] | |||||||||||||||||||||||||||||||||||||||||
|
Ok, I've now made a 10.1 tree with a fix for elenst, could you make another testing pass? | |||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2014-10-22 ] | |||||||||||||||||||||||||||||||||||||||||
|
Checked EXPLAINs again - there are no regressions in current 10.1. Too bad we can't add these testcases to the test suite. |