[MDEV-16387] Unstable execution plan for select from RocksDB table Created: 2018-06-04  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: Optimizer, Storage Engine - RocksDB, Tests
Affects Version/s: 10.2, 10.3
Fix Version/s: 10.4

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


 Description   

The following test

CREATE TABLE t1 (
  b BINARY,
  b20 BINARY(20),
  v16 VARBINARY(16),
  v128 VARBINARY(128),
  INDEX (v16(10))
) ENGINE=RocksDB;
INSERT INTO t1 (b,b20,v16,v128) VALUES ('a','char1','varchar1a','varchar1b'),('a','char2','varchar2a','varchar2b'),('b','char3','varchar1a','varchar1b'),('c','char4','varchar3a','varchar3b'),('d','char5','varchar4a','varchar3b'),('e','char6','varchar2a','varchar3b');
INSERT INTO t1 (b,b20,v16,v128) SELECT b,b20,v16,v128 FROM t1;
ANALYZE TABLE t1;
EXPLAIN SELECT HEX(SUBSTRING(v16,0,3)) FROM t1 WHERE v16 LIKE 'varchar%';
DROP TABLE t1;

produces at least two essentially different execution plans:

MariaDB [test]> EXPLAIN SELECT HEX(SUBSTRING(v16,0,3)) FROM t1 WHERE v16 LIKE 'varchar%';
+------+-------------+-------+------+---------------+------+---------+------+------+-------------+
| id   | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+------+-------------+-------+------+---------------+------+---------+------+------+-------------+
|    1 | SIMPLE      | t1    | ALL  | v16           | NULL | NULL    | NULL |   24 | Using where |
+------+-------------+-------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)

and

MariaDB [test]> EXPLAIN SELECT HEX(SUBSTRING(v16,0,3)) FROM t1 WHERE v16 LIKE 'varchar%';
+------+-------------+-------+-------+---------------+------+---------+------+------+-------------+
| id   | select_type | table | type  | possible_keys | key  | key_len | ref  | rows | Extra       |
+------+-------------+-------+-------+---------------+------+---------+------+------+-------------+
|    1 | SIMPLE      | t1    | range | v16           | v16  | 13      | NULL |   10 | Using where |
+------+-------------+-------+-------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)

I think it started happening after the last big merge from upstream, at least now storage_engine-rocksdb.type_binary_indexes test in the storage_engine suite which checks for key in the plan fails regularly, it didn't before.

Maybe it's not important, then indicate so and assign back to me, so I'd disable the test for RocksDB.



 Comments   
Comment by Elena Stepanova [ 2018-06-25 ]

rocksdb.mariadb_port_fixes fails in a similar fashion:
http://buildbot.askmonty.org/buildbot/builders/kvm-deb-xenial-amd64/builds/3611

rocksdb.mariadb_port_fixes               w1 [ fail ]
        Test ended at 2018-06-21 16:23:00
 
CURRENT_TEST: rocksdb.mariadb_port_fixes
--- /usr/share/mysql/mysql-test/plugin/rocksdb/rocksdb/r/mariadb_port_fixes.result	2018-06-21 07:23:57.000000000 -0400
+++ /dev/shm/var/1/log/mariadb_port_fixes.reject	2018-06-21 16:23:00.194600434 -0400
@@ -52,7 +52,7 @@
 insert into t2 values (1,1,1),(2,2,2);
 explain select a from t2 where a <'zzz';
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
-1	SIMPLE	t2	range	a	a	32	NULL	#	Using where
+1	SIMPLE	t2	ALL	a	NULL	NULL	NULL	#	Using where
 drop table t1,t2;
 set global rocksdb_strict_collation_check=@tmp_rscc;
 #
 
mysqltest: Result length mismatch

Generated at Thu Feb 08 08:28:32 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.