UPDATE for table with VARCHAR pk gives "Can't find record" error

[spetrunia]

UPDATE for table with VARCHAR pk gives "Can't find record" error

[spetrunia]

The reason for this is as follows:

• rowids are mem-comparable forms of PK.
• mem-comparable forms of PK used to be fixed-length for MyRocks, but since "efficient varchar encoding" they are variable-length.
• However, MySQL assumes that rowids have fixed length. Currently rowids are zero-padded.
• When MyRocks attempt to do a PK lookup for rnd_pos(zero-padded-rowid), the record is not found and we have an error.

[spetrunia]

Possible solutions:

S1. Let the rowid be PK in KeyTupleFormat. KeyTupleFormat is fixed-length.

• We will have to provide ha_rocksdb::cmp_ref() function
• (TODO: is it possible to provide the original (non-mem-comparable) form of PK columns in all cases where MyRocks needs to return a rowid?)

S2. Keep the rowid being mem-comparable form.

• We will have to know how much end-space bytes are padding, and ha_rocksdb::rnd_pos() should strip them off before doing the index lookup.

[spetrunia]

is it possible to provide the original (non-mem-comparable) form of PK columns in all cases where MyRocks needs to return a rowid?)

This doesn't work in all cases.
Consider a case where the PK column uses case-sensitive collation (so one can't restore the value from its mem-comparable form).
Then, suppose we're doing an index-only scan on a secondary index.

In this case, secondary index only gives mem-comparable form of PK columns. We can't restore the original values, and so we can return them in KeyTupleFormat

[spetrunia]

We will have to know how much end-space bytes are padding, and ha_rocksdb::rnd_pos() should strip them off before doing the index lookup.

This looks feasible. mem-comparable images of keys are traversed by skip_func which has two possible values:
A. skip_max_length
B. skip_variable_length

skip_variable_length skips data in "varchar encoding". Varchar encoding means 9-byte groups, where the 9th byte varies between 0xFF (no padding bytes) to 0xF7 (all 8 bytes were padding bytes).

That is, if the next 9-byte group is padding it has all zeros, it is zero-padding, otherwise it is not.
If there is less than 9-byte data, it is zero-padding.

[spetrunia]

https://reviews.facebook.net/D45639