[MDEV-23541] Assertion `cost > 0.0' failed in adjust_quick_cost with mrr_sort_keys and not_null_range_scan on partitioned table Created: 2020-08-22  Updated: 2021-03-19

Status: Open
Project: MariaDB Server
Component/s: Optimizer, Partitioning
Affects Version/s: 10.5
Fix Version/s: 10.5

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Setting it to Minor due to the incorrect data type in WHERE clause and non-default optimizer switch.

--source include/have_sequence.inc
--source include/have_partition.inc
 
CREATE TABLE t1 (a INT, b DATE, KEY (a), KEY (b)) ENGINE=MyISAM PARTITION BY KEY(a);
INSERT INTO t1 SELECT seq, DATE_ADD('1500-01-01', INTERVAL seq DAY) FROM seq_1_to_250000;
SET SESSION optimizer_switch= 'mrr=on,mrr_sort_keys=on,not_null_range_scan=on';
SELECT * FROM t1 WHERE b = 1;
 
# Cleanup
DROP TABLE t1;

10.5 6708e67a

mariadbd: /data/src/10.5/sql/sql_select.cc:7280: double adjust_quick_cost(double, ha_rows): Assertion `cost > 0.0' failed.
200823  0:37:18 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fdc79a6cf12 in __GI___assert_fail (assertion=0x559eaf8cf806 "cost > 0.0", file=0x559eaf8ce578 "/data/src/10.5/sql/sql_select.cc", line=7280, function=0x559eaf8d33c0 <adjust_quick_cost(double, unsigned long long)::__PRETTY_FUNCTION__> "double adjust_quick_cost(double, ha_rows)") at assert.c:101
#8  0x0000559eaeb7b651 in adjust_quick_cost (quick_cost=7195.4144317757227, records=250000) at /data/src/10.5/sql/sql_select.cc:7280
#9  0x0000559eaeb7c21d in best_access_path (join=0x7fdc64015520, s=0x7fdc640160a8, remaining_tables=1, join_positions=0x7fdc64016658, idx=0, disable_jbuf=true, record_count=1, pos=0x7fdc64016658, loose_scan_pos=0x7fdc74606f60) at /data/src/10.5/sql/sql_select.cc:7547
#10 0x0000559eaeb8203c in best_extension_by_limited_search (join=0x7fdc64015520, remaining_tables=1, idx=0, record_count=1, read_time=0, search_depth=62, prune_level=1, use_cond_selectivity=4) at /data/src/10.5/sql/sql_select.cc:9539
#11 0x0000559eaeb7ff71 in greedy_search (join=0x7fdc64015520, remaining_tables=1, search_depth=62, prune_level=1, use_cond_selectivity=4) at /data/src/10.5/sql/sql_select.cc:8742
#12 0x0000559eaeb7f1be in choose_plan (join=0x7fdc64015520, join_tables=1) at /data/src/10.5/sql/sql_select.cc:8307
#13 0x0000559eaeb76a82 in make_join_statistics (join=0x7fdc64015520, tables_list=..., keyuse_array=0x7fdc64015810) at /data/src/10.5/sql/sql_select.cc:5547
#14 0x0000559eaeb6a712 in JOIN::optimize_inner (this=0x7fdc64015520) at /data/src/10.5/sql/sql_select.cc:2242
#15 0x0000559eaeb6822a in JOIN::optimize (this=0x7fdc64015520) at /data/src/10.5/sql/sql_select.cc:1618
#16 0x0000559eaeb734e7 in mysql_select (thd=0x7fdc64000b18, tables=0x7fdc640140e8, fields=..., conds=0x7fdc640149b8, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fdc640154f8, unit=0x7fdc64004cb0, select_lex=0x7fdc64013af0) at /data/src/10.5/sql/sql_select.cc:4641
#17 0x0000559eaeb63226 in handle_select (thd=0x7fdc64000b18, lex=0x7fdc64004be8, result=0x7fdc640154f8, setup_tables_done_option=0) at /data/src/10.5/sql/sql_select.cc:429
#18 0x0000559eaeb27492 in execute_sqlcom_select (thd=0x7fdc64000b18, all_tables=0x7fdc640140e8) at /data/src/10.5/sql/sql_parse.cc:6210
#19 0x0000559eaeb1e739 in mysql_execute_command (thd=0x7fdc64000b18) at /data/src/10.5/sql/sql_parse.cc:3932
#20 0x0000559eaeb2c2df in mysql_parse (thd=0x7fdc64000b18, rawbuf=0x7fdc64013a50 "SELECT * FROM t1 WHERE b = 1", length=28, parser_state=0x7fdc74608520, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:7994
#21 0x0000559eaeb185d8 in dispatch_command (command=COM_QUERY, thd=0x7fdc64000b18, packet=0x7fdc640087a9 "SELECT * FROM t1 WHERE b = 1", packet_length=28, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1868
#22 0x0000559eaeb16d06 in do_command (thd=0x7fdc64000b18) at /data/src/10.5/sql/sql_parse.cc:1349
#23 0x0000559eaecbdca4 in do_handle_one_connection (connect=0x559eb3030a18, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1410
#24 0x0000559eaecbda0c in handle_one_connection (arg=0x559eb3030a18) at /data/src/10.5/sql/sql_connect.cc:1312
#25 0x0000559eaf1ff632 in pfs_spawn_thread (arg=0x559eb3030648) at /data/src/10.5/storage/perfschema/pfs.cc:2201
#26 0x00007fdc7b9f54a4 in start_thread (arg=0x7fdc74609700) at pthread_create.c:456
#27 0x00007fdc79b29d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible with MyISAM and Aria. Couldn't reproduce with InnoDB.
Couldn't reproduce without partitioning.
Couldn't reproduce on 10.4 (without not_null_range_scan).
No obvious problem on a non-debug build, but it's possible that something is wrong with the plan:

ANALYZE
{
  "query_block": {
    "select_id": 1,
    "r_loops": 1,
    "r_total_time_ms": 0.009770149,
    "table": {
      "table_name": "t1",
      "partitions": ["p0"],
      "access_type": "ref",
      "possible_keys": ["b"],
      "key": "b",
      "key_length": "4",
      "used_key_parts": ["b"],
      "ref": ["const"],
      "r_loops": 1,
      "rows": 250000,
      "r_rows": 0,
      "r_table_time_ms": 0.003905275,
      "r_other_time_ms": 0.002429033,
      "filtered": 100,
      "r_filtered": 100,
      "attached_condition": "t1.b = 1"
    }
  }
}

If I put a valid date value in the WHERE clause instead, the assertion failure on a debug build goes away, and the plan on a non-debug build changes:

ANALYZE
{
  "query_block": {
    "select_id": 1,
    "r_loops": 1,
    "r_total_time_ms": 0.015103378,
    "table": {
      "table_name": "t1",
      "partitions": ["p0"],
      "access_type": "ref",
      "possible_keys": ["b"],
      "key": "b",
      "key_length": "4",
      "used_key_parts": ["b"],
      "ref": ["const"],
      "r_loops": 1,
      "rows": 1,
      "r_rows": 1,
      "r_table_time_ms": 0.008360501,
      "r_other_time_ms": 0.003273603,
      "filtered": 100,
      "r_filtered": 100
    }
  }
}


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