[MDEV-30568] Assertion `cond_selectivity <= 1.000000001' failed in get_range_limit_read_cost on empty Merge table Created: 2023-02-04  Updated: 2023-02-10  Resolved: 2023-02-06

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

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
is caused by MDEV-26974 Improve selectivity and related costs... Closed
Relates

 Description   

CREATE TABLE t1 (f INT, KEY(f)) ENGINE=MyISAM;
CREATE TABLE t2 (f INT, KEY(f)) ENGINE=MyISAM;
CREATE TABLE tm (f INT, KEY(f)) ENGINE=MERGE UNION = (t1, t2);
SELECT DISTINCT f FROM tm WHERE f IN (47, 126, 97, 48, 73, 0);
 
# Cleanup
DROP TABLE tm, t1, t2;

bb-11.0 a6a9c89266

 mariadbd: /mnt8t/src/bb-11.0/sql/sql_select.cc:30473: bool get_range_limit_read_cost(const POSITION*, const TABLE*, uint, ha_rows, ha_rows, double*, double*): Assertion `cond_selectivity <= 1.000000001' failed.
230204 20:32:41 [ERROR] mysqld got signal 6 ;
 
#9  0x00007f1453384df2 in __GI___assert_fail (assertion=0x55c148a3d1e0 "cond_selectivity <= 1.000000001", file=0x55c148a2bd20 "/data/src/bb-11.0/sql/sql_select.cc", line=30473, function=0x55c148a3d220 "bool get_range_limit_read_cost(const POSITION*, const TABLE*, uint, ha_rows, ha_rows, double*, double*)") at ./assert/assert.c:101
#10 0x000055c146bbd105 in get_range_limit_read_cost (pos=0x62900026cce0, table=0x61900008b198, keynr=0, rows_limit_arg=1, rows_to_scan=0, read_cost=0x7f144a065bf0, read_rows=0x7f144a065c10) at /data/src/bb-11.0/sql/sql_select.cc:30473
#11 0x000055c146bbf071 in test_if_cheaper_ordering (tab=0x62900026d620, order=0x6290000ea120, table=0x61900008b198, usable_keys=..., ref_key=-1, select_limit_arg=0, new_key=0x7f144a065ef0, new_key_direction=0x7f144a065f20, new_select_limit=0x7f144a065fb0, new_used_key_parts=0x7f144a065f00, saved_best_key_parts=0x7f144a065f10) at /data/src/bb-11.0/sql/sql_select.cc:30833
#12 0x000055c146b989dc in test_if_skip_sort_order (tab=0x62900026d620, order=0x6290000ea120, select_limit=18446744073709551615, no_changes=false, map=0x61900008b228) at /data/src/bb-11.0/sql/sql_select.cc:25751
#13 0x000055c146af2215 in JOIN::optimize_stage2 (this=0x6290000e9100) at /data/src/bb-11.0/sql/sql_select.cc:3279
#14 0x000055c146aeb129 in JOIN::optimize_inner (this=0x6290000e9100) at /data/src/bb-11.0/sql/sql_select.cc:2595
#15 0x000055c146ae3f69 in JOIN::optimize (this=0x6290000e9100) at /data/src/bb-11.0/sql/sql_select.cc:1897
#16 0x000055c146b05434 in mysql_select (thd=0x62b00007e218, tables=0x6290000e6950, fields=..., conds=0x6290000e7628, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2164525825, result=0x6290000e90d0, unit=0x62b000082660, select_lex=0x6290000e6320) at /data/src/bb-11.0/sql/sql_select.cc:5112
#17 0x000055c146ad5d90 in handle_select (thd=0x62b00007e218, lex=0x62b000082588, result=0x6290000e90d0, setup_tables_done_option=0) at /data/src/bb-11.0/sql/sql_select.cc:608
#18 0x000055c1469ff028 in execute_sqlcom_select (thd=0x62b00007e218, all_tables=0x6290000e6950) at /data/src/bb-11.0/sql/sql_parse.cc:6265
#19 0x000055c1469ed995 in mysql_execute_command (thd=0x62b00007e218, is_called_from_prepared_stmt=false) at /data/src/bb-11.0/sql/sql_parse.cc:3949
#20 0x000055c146a09914 in mysql_parse (thd=0x62b00007e218, rawbuf=0x6290000e6238 "SELECT DISTINCT f FROM tm WHERE f IN (47, 126, 97, 48, 73, 0)", length=61, parser_state=0x7f144a067a20) at /data/src/bb-11.0/sql/sql_parse.cc:8000
#21 0x000055c1469e0374 in dispatch_command (command=COM_QUERY, thd=0x62b00007e218, packet=0x629000253219 "SELECT DISTINCT f FROM tm WHERE f IN (47, 126, 97, 48, 73, 0)", packet_length=61, blocking=true) at /data/src/bb-11.0/sql/sql_parse.cc:1894
#22 0x000055c1469dd119 in do_command (thd=0x62b00007e218, blocking=true) at /data/src/bb-11.0/sql/sql_parse.cc:1407
#23 0x000055c146e8f81e in do_handle_one_connection (connect=0x608000002638, put_in_cache=true) at /data/src/bb-11.0/sql/sql_connect.cc:1416
#24 0x000055c146e8f1b4 in handle_one_connection (arg=0x6080000025b8) at /data/src/bb-11.0/sql/sql_connect.cc:1318
#25 0x000055c147a76086 in pfs_spawn_thread (arg=0x617000004d98) at /data/src/bb-11.0/storage/perfschema/pfs.cc:2201
#26 0x00007f14533d8fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#27 0x00007f145345966c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81



 Comments   
Comment by Sergei Petrunia [ 2023-02-06 ]

It fails here:

        double cond_selectivity= best_rows / range_rows;
=>      DBUG_ASSERT(cond_selectivity <= 1.000000001);

(gdb) print cond_selectivity
  $7 = -nan(0x8000000000000)
(gdb) print range_rows
  $9 = 0
(gdb) print best_rows
  $11 = 0

Comment by Sergei Petrunia [ 2023-02-06 ]

Why is this visible with Merge tables but not other storage engines?

Merge tables have:

(table->file->ha_table_flags() & HA_STATS_RECORDS_IS_EXACT) == 0

but also can have

table->file->records()=0 

Comment by Sergei Petrunia [ 2023-02-06 ]

Fixed in bb-11.0 tree

Generated at Thu Feb 08 10:17:13 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.