[MDEV-22183]  Assertion `tmp >= 0' failed in best_access_path with rowid_filter=ON Created: 2020-04-07  Updated: 2020-05-29  Resolved: 2020-05-29

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.5
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Alice Sherepa Assignee: Sergei Petrunia
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by MDEV-21633 Assertion `tmp >= 0' failed in best_a... Stalled
Relates
relates to MDEV-21633 Assertion `tmp >= 0' failed in best_a... Stalled

 Description   

SET optimizer_switch='rowid_filter=on';
 
create table t1 (pk int not null primary key, i1 varchar(10), i2 int, i3 int , key i2 (i2), key (i2,i3,pk)) engine=myisam;
insert into t1 values (45,null,null,null),(46,null,null,null),(44,null,null,null),(43,null,null,null),(49,null,null,null),(50,null,null,null),(51,null,null,null),(52,null,null,null),(53,null,null,null),(54,null,null,null),(55,null,null,null),(56,null,null,null),(57,null,null,null),(58,null,null,null),(59,null,null,null),(60,null,null,null),(61,null,null,null),(62,null,null,null),(63,null,null,null),(64,null,null,null),(65,null,null,null);
 
select straight_join  1 
from t1 join t1 as a2 on t1.i1 = a2.i1
where a2.pk > 4 and a2.pk < 6
  and a2.i3 >= 2 and a2.i2 in (4, 6, 7);

10.5 0eab87cef26eaac2c

#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#5  0x00007f3f7238b535 in __GI_abort () at abort.c:79
#6  0x00007f3f7238b40f in __assert_fail_base (fmt=0x7f3f724edee0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x560604d4612f "tmp >= 0", file=0x560604d44e78 "/10.5/sql/sql_select.cc", line=7977, function=<optimized out>) at assert.c:92
#7  0x00007f3f72399102 in __GI___assert_fail (assertion=0x560604d4612f "tmp >= 0", file=0x560604d44e78 "/10.5/sql/sql_select.cc", line=7977, function=0x560604d49b00 <best_access_path(JOIN*, st_join_table*, unsigned long long, st_position const*, unsigned int, bool, double, st_position*, st_position*)::__PRETTY_FUNCTION__> "void best_access_path(JOIN*, JOIN_TAB*, table_map, const POSITION*, uint, bool, double, POSITION*, POSITION*)") at assert.c:101
#8  0x000056060400adc4 in best_access_path (join=0x7f3f5c017988, s=0x7f3f5c018af0, remaining_tables=2, join_positions=0x7f3f5c0190b8, idx=1, disable_jbuf=false, record_count=21, pos=0x7f3f5c0191e8, loose_scan_pos=0x7f3f6cd4b140) at /10.5/sql/sql_select.cc:7977
#9  0x000056060400c790 in optimize_straight_join (join=0x7f3f5c017988, join_tables=2) at /10.5/sql/sql_select.cc:8596
#10 0x000056060400be58 in choose_plan (join=0x7f3f5c017988, join_tables=3) at /10.5/sql/sql_select.cc:8299
#11 0x0000560604003ad1 in make_join_statistics (join=0x7f3f5c017988, tables_list=..., keyuse_array=0x7f3f5c017c78) at /10.5/sql/sql_select.cc:5554
#12 0x0000560603ff7962 in JOIN::optimize_inner (this=0x7f3f5c017988) at /10.5/sql/sql_select.cc:2260
#13 0x0000560603ff5282 in JOIN::optimize (this=0x7f3f5c017988) at /10.5/sql/sql_select.cc:1606
#14 0x00005606040006cb in mysql_select (thd=0x7f3f5c000d78, tables=0x7f3f5c014258, fields=..., conds=0x7f3f5c016588, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748610, result=0x7f3f5c017960, unit=0x7f3f5c004d80, select_lex=0x7f3f5c013d00) at /10.5/sql/sql_select.cc:4654
#15 0x0000560603ff042a in handle_select (thd=0x7f3f5c000d78, lex=0x7f3f5c004cb8, result=0x7f3f5c017960, setup_tables_done_option=0) at /10.5/sql/sql_select.cc:417
#16 0x0000560603fb5c83 in execute_sqlcom_select (thd=0x7f3f5c000d78, all_tables=0x7f3f5c014258) at /10.5/sql/sql_parse.cc:6168
#17 0x0000560603fac7c2 in mysql_execute_command (thd=0x7f3f5c000d78) at /10.5/sql/sql_parse.cc:3901
#18 0x0000560603fbabb2 in mysql_parse (thd=0x7f3f5c000d78, rawbuf=0x7f3f5c013b90 "select straight_join  1 \nfrom t1 join t1 as a2 on t1.i1 = a2.i1\nwhere a2.pk > 4 and a2.pk < 6\nand a2.i3 >= 2 and a2.i2 in (4, 6, 7)", length=131, parser_state=0x7f3f6cd4c510, is_com_multi=false, is_next_command=false) at /10.5/sql/sql_parse.cc:7953
#19 0x0000560603fa6546 in dispatch_command (command=COM_QUERY, thd=0x7f3f5c000d78, packet=0x7f3f5c008d09 "select straight_join  1 \nfrom t1 join t1 as a2 on t1.i1 = a2.i1\nwhere a2.pk > 4 and a2.pk < 6\nand a2.i3 >= 2 and a2.i2 in (4, 6, 7)", packet_length=131, is_com_multi=false, is_next_command=false) at /10.5/sql/sql_parse.cc:1839
#20 0x0000560603fa4c84 in do_command (thd=0x7f3f5c000d78) at /10.5/sql/sql_parse.cc:1358
#21 0x00005606041464f2 in do_handle_one_connection (connect=0x56060863f778, put_in_cache=true) at /10.5/sql/sql_connect.cc:1422
#22 0x0000560604146222 in handle_one_connection (arg=0x56060855ec18) at /10.5/sql/sql_connect.cc:1319
#23 0x0000560604675181 in pfs_spawn_thread (arg=0x56060863f3b8) at /10.5/storage/perfschema/pfs.cc:2201
#24 0x00007f3f72e31fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#25 0x00007f3f724624cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95



 Comments   
Comment by Varun Gupta (Inactive) [ 2020-05-29 ]

Same problem of selectivity estimates when estimates are taken from multi-keypart key but the plan picked for range scan is on a different index.

From the optimizer trace

                    "range_scan_alternatives": [
                      {
                        "index": "PRIMARY",
                        "ranges": ["(4) < (pk) < (6)"],
                        "rowid_ordered": false,
                        "using_mrr": false,
                        "index_only": false,
                        "rows": 1,
                        "cost": 1.345488162,
                        "chosen": true
                      },
                      {
                        "index": "i2",
                        "ranges": [
                          "(4) <= (i2) <= (4)",
                          "(6) <= (i2) <= (6)",
                          "(7) <= (i2) <= (7)"
                        ],
                        "rowid_ordered": false,
                        "using_mrr": false,
                        "index_only": false,
                        "rows": 3,
                        "cost": 3.996610935,
                        "chosen": false,
                        "cause": "cost"
                      },
                      {
                        "index": "i2_2",
                        "ranges": [
                          "(4,2,4) < (i2,i3,pk) <= (4)",
                          "(6,2,4) < (i2,i3,pk) <= (6)",
                          "(7,2,4) < (i2,i3,pk) <= (7)"
                        ],
                        "rowid_ordered": false,
                        "using_mrr": false,
                        "index_only": false,
                        "rows": 3,
                        "cost": 3.997928972,
                        "chosen": false,
                        "cause": "cost"
                      }

For primary key we get rows= 1 as estimate while for the key i2_2 we get 3 as an estimate.

                  "chosen_range_access_summary": {
                    "range_access_plan": {
                      "type": "range_scan",
                      "index": "PRIMARY",
                      "rows": 1,
                      "ranges": ["(4) < (pk) < (6)"]
                    },
                    "rows_for_plan": 1,
                    "cost_for_plan": 1.345488162,
                    "chosen": true
                  }

Generated at Thu Feb 08 09:12:49 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.