Hello, I think me and Serg have tried having this discussion before on several occasions but were not successful due to me not having the details back then. Now I'm trying with the details. == Description of the issue == Look at MariaDB, the code in TABLE_SHARE::init_from_binary_frm_image (or open_binary_frm() in mysql-5.6 codebase) The code goes like this: ... /* Allocate handler */ if (!(handler_file= get_new_handler(share, thd->mem_root, plugin_hton(se_plugin)))) // ^(LOCATION-1) ... /* Fix key->name and key_part->field */ if (key_parts) { longlong ha_option= handler_file->ha_table_flags(); // ^(LOCATION-2) ... for (uint key=0 ; key < keys ; key++,keyinfo++) { ... for (i=0; i < key_parts; key_part++, i++) { ... field= key_part->field= share->field[key_part->fieldnr-1]; // (LOCATION-3) ... } } Note that - a handler object is created at (LOCATION-1). A TABLE_SHARE object exists at that point, but it has table_share->key_info==NULL. This means the storage object has no information about the indexes in the table it is representing. - At (LOCATION-2), the code retrieves ha_table_flags(). A bit below that point it checks for "ha_option & HA_PRIMARY_KEY_IN_READ_INDEX" (there are also other checks, both harmful and harmless, but let's focus on this one for now). In MyRocks, whether HA_PRIMARY_KEY_IN_READ_INDEX flag is set depends on the datatypes of the primary key columns. However, ha_rocksdb object is requested to provide ha_table_flags() before it has a chance of looking at the table DDL and actually knowing the value. == Solution in MyRocks == It's here: https://github.com/facebook/mysql-5.6/commit/c1f1f0b64eaecd132fc6ec21663faf0... Basically, there is a new handler::init_with_fields() call which SQL layer calls after information about table fields is filled. == Questions == Any objections to this approach? Alternative solutions that do not require a lot of re-writing? BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog