[MDEV-11194] MariaRocks: rocksdb.rocksdb_range test failure Created: 2016-10-31  Updated: 2017-10-26  Resolved: 2017-10-26

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - RocksDB
Affects Version/s: N/A
Fix Version/s: 10.2.10

Type: Bug Priority: Major
Reporter: Sergei Petrunia Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: rocksdb

Issue Links:
PartOf
is part of MDEV-9658 Make MyRocks in MariaDB stable Closed

 Description   

rocksdb.rocksdb_range test fails. there are also other similar test failures.

CURRENT_TEST: rocksdb.rocksdb_range
 
--- /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/mysql-test/rocksdb/r/rocksdb_range.result     2016-10-26 21:41:21.688861122 +0000
 
+++ /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/mysql-test/rocksdb/r/rocksdb_range.reject     2016-10-30 21:08:55.290270527 +0000
 
@@ -89,7 +89,7 @@
 
 explain
 
 select * from t2 force index (a) where a=0 and pk>=3;
 
 id     select_type     table   type    possible_keys   key     key_len ref     rows    Extra
 
-1      SIMPLE  t2      range   a       a       8       NULL    #       Using index condition
 
+1      SIMPLE  t2      range   a       a       8       NULL    #       Using index condition; Using where
 
 select * from t2 force index (a) where a=0 and pk>=3;
 
 pk     a       b
 
 3      0       3
 
@@ -201,7 +201,7 @@
 
 explain
 
 select * from t2 where a between 99 and 2000 order by a desc;
 
 id     select_type     table   type    possible_keys   key     key_len ref     rows    Extra
 
-1      SIMPLE  t2      range   a       a       4       NULL    #       Using index condition
 
+1      SIMPLE  t2      range   a       a       4       NULL    #       Using where
 
 select * from t2 where a between 99 and 2000 order by a desc;
 
 pk     a       b
 
 999    99      999
 
 
 
mysqltest: Result length mismatch

The reason it fails is that MyRocks (or MariaRocks) does not return the 

table_flags() & HA_PRIMARY_KEY_IN_READ_INDEX

flag. See https://github.com/facebook/mysql-5.6/issues/376 for details.

This doesn't prevent Index Condition Pushdown in MySQL, but it does prevent it in MariaDB.

 Comments   
Comment by Sergei Petrunia [ 2016-12-02 ]

Committed the facebook/mysql-5.6 approach as this patch:

https://github.com/MariaDB/server/commit/59d76665eed69974da81cdccba2df9f26b4e0967

Comment by Sergei Petrunia [ 2016-12-02 ]

... the patch makes this result difference go away:

@@ -89,7 +89,7 @@
 
 explain
 
 select * from t2 force index (a) where a=0 and pk>=3;
 
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
 
-1	SIMPLE	t2	range	a	a	8	NULL	#	Using index condition
 
+1	SIMPLE	t2	range	a	a	8	NULL	#	Using index condition; Using where
 
 select * from t2 force index (a) where a=0 and pk>=3;
 
 pk	a	b
 
 3	0	3

but the second EXPLAIN difference, for 

@@ -201,7 +201,7 @@
 
 explain
 
 select * from t2 where a between 99 and 2000 order by a desc;
 
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
 
-1	SIMPLE	t2	range	a	a	4	NULL	#	Using index condition
 
+1	SIMPLE	t2	range	a	a	4	NULL	#	Using where
 
 select * from t2 where a between 99 and 2000 order by a desc;
 
 pk	a	b
 
 999	99	999

is still there.

Note: the patch also fixes this failure in rocksdb.rocksdb_part

@@ -73,7 +73,7 @@
 
 # The following must use "Using index"
 
 explain select pk from t1 force index(col1) where col1=10;
 
 id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
 
-1	SIMPLE	t1	ref	col1	col1	5	const	2000	Using index
 
+1	SIMPLE	t1	ref	col1	col1	5	const	2000	
 drop table t1;
 
 #
 
 # Issue #214: subqueries cause crash

Comment by Sergei Petrunia [ 2016-12-02 ]

The second result difference is caused by Index Condition Pushdown not working for "ORDER BY ... DESC" .

MySQL has a fix for it (with set_end_range call), MariaDB doesn't.

Comment by Sergei Petrunia [ 2016-12-02 ]

The set_end_range call itself was ported into MariaDB :

https://github.com/MariaDB/server/commit/94d722b6a43b86ee760f07915921cf58f9869a5d

however, some code with set_end_range was not ported:

  • the calls to set_end_range from opt_range.cc, QUICK_SELECT_DESC::get_next
  • the logic that enables ICP for reverse index scans (it's logical not to port this when we dont have the previous item)
Comment by Daniel Black [ 2017-05-05 ]

tests seem fine as of 96247be1a0dfa3035580b53b1c27a7247a410713. Can this be closed?

Comment by Sergei Petrunia [ 2017-10-26 ]

Yes, they seems to be ok now, as well. Closing.

Generated at Thu Feb 08 07:48:02 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.