[MDEV-11477] MariaRocks: rocksdb.type_varchar failure Created: 2016-12-02  Updated: 2016-12-02  Resolved: 2016-12-02

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

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

Issue Links:
PartOf
is part of MDEV-9658 Make MyRocks in MariaDB stable Closed
Relates
relates to MDEV-11321 MariaRocks: type_binary_indexes, type... Closed

 Description   

rocksdb.type_varchar fails like this:

CURRENT_TEST: rocksdb.type_varchar
 
--- /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/mysql-test/rocksdb/r/type_varchar.result      2016-10-28 08:55:37.056371707 +0000
 
+++ /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/mysql-test/rocksdb/r/type_varchar.reject      2016-12-02 19:14:06.552690598 +0000
 
@@ -721,7 +721,7 @@
 
 insert into t values (1, 'abcabcabcabcabcabcabcabcabcabcabc  ');
 
 explain select 'email_i' as index_name, count(*) AS count from t force index(email_i);
 
 id     select_type     table   type    possible_keys   key     key_len ref     rows    Extra
 
-1      SIMPLE  t       index   NULL    email_i 33      NULL    #       Using index
 
+1      SIMPLE  t       ALL     NULL    NULL    NULL    NULL    #
 
 select 'email_i' as index_name, count(*) AS count from t force index(email_i);
 
 index_name     count
 
 email_i        1
 
@@ -734,7 +734,7 @@
 
 insert into t values (1, 'a');
 
 explain select 'email_i' as index_name, count(*) AS count from t force index(email_i);
 
 id     select_type     table   type    possible_keys   key     key_len ref     rows    Extra
 
-1      SIMPLE  t       index   NULL    email_i 33      NULL    #       Using index
 
+1      SIMPLE  t       ALL     NULL    NULL    NULL    NULL    #
 
 select 'email_i' as index_name, count(*) AS count from t force index(email_i);
 
 index_name     count
 
 email_i        1

Initially this was reported here:
https://jira.mariadb.org/browse/MDEV-9658?focusedCommentId=87896&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-87896

but in the current tree, I see the same field->part_of_key for both MariaDB and MySQL:

(gdb) p tables_arg->table->field[0]->part_of_key
 
  warning: can't find linker symbol for virtual table for `Field' value
 
  $89 = {map = 3}
 
(gdb) p tables_arg->table->field[1]->part_of_key
 
  warning: can't find linker symbol for virtual table for `Field' value
 
  $90 = {map = 0}



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

At start of make_join_statistics:

MariaDB:
 
(gdb) p tables_list.head()->table->covering_keys
 
  $306 = {map = 0}
 
 
 
MySQL:
 
(gdb) p table->covering_keys
 
  $94 = {map = 2}

covering_keys is initially set in setup_table_map():

MySQL:
 
(gdb) p table->s->keys_for_keyread
 
  $108 = {map = 3}
 
 
 
MariaDB:
 
(gdb) p table->s->keys_for_keyread
 
  $317 = {map = 1}

In both cases, setup_table_map does this:

  table->covering_keys= table->s->keys_for_keyread;

Comment by Sergei Petrunia [ 2016-12-02 ]

keys_for_keyread is set in

  • MySQL: setup_key_part_field(), which is called from open_binary_frm(),
  • MariaDB: TABLE_SHARE::init_from_binary_frm_image()

In both cases, this is a chunk of code like this:

        if (field->key_length() == key_part->length &&
 
            !(field->flags & BLOB_FLAG))
 
        {
 
          if (handler_file->index_flags(key, i, 0) & HA_KEYREAD_ONLY)
 
          {
 
            share->keys_for_keyread.set_bit(key);
 
            field->part_of_key.set_bit(key);

And when proceessing the email_i index from

create table t (id int primary key, email varchar(100), KEY email_i (email(30)));

MySQL will execute the above code for id as the second key part. MariaDB won't, because of its "keys with partially-columns are not extended" property.

This is why the execution is different. This case is

  • not related to MyRocks
  • an edge case (how often does it happen that all key components are partial?)

I'll just update the test result.

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