Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support index-only scans for collations other than _bin #28

Open
hermanlee opened this issue Sep 28, 2015 · 3 comments
Open

Support index-only scans for collations other than _bin #28

hermanlee opened this issue Sep 28, 2015 · 3 comments

Comments

@hermanlee
Copy link
Contributor

hermanlee commented Sep 28, 2015

Issue by spetrunia
Friday Jan 30, 2015 at 12:54 GMT
Originally opened as MySQLOnRocksDB#25


Currently, index-only scans are supported for

  • numeric columns
  • varchar columns with BINARY, latin1_bin, utf8_bin collation.

for other collations (eg. case-insensitive, _ci collations), index-only scans are not supported. The reason for this is that is not possible to restore the original column value mem-comparable key. For example, in latin_general_ci both 'foo', 'Foo', and 'FOO' have mem-comparable form 'FOO'.

A possible solution could work like this:

  1. In addition to value->mem_comparable_form function, develop value->(mem_comparable_form, restore_data) function. This is easy for some charsets.
  2. store restore_data in RocksDB's value part of the key-value pair. We already used to store information about VARCHAR field length there, but now the value part is unused.

See also:


Diffs:
https://reviews.facebook.net/D58269
https://reviews.facebook.net/D58503
https://reviews.facebook.net/D58875

@hermanlee
Copy link
Contributor Author

Comment by yoshinorim
Monday Feb 02, 2015 at 12:11 GMT


I like space optimization for cs collation, that is:

  • (mem_comparable_form) for cs collation, not storing any duplicates for cs collation
  • (mem_comparable_form, restore_data) for ci collation, and storing restore_data into value part of the key-value pair.

@hermanlee
Copy link
Contributor Author

Comment by spetrunia
Monday Feb 02, 2015 at 16:40 GMT


Exploring how to make a bi-directional mapping

 value <=> (mem_comparable_form, restore_data).

latin1_swedish_ci, latin1_general_ci, (and other collations) have these properties:

  • strxfrm(char c) returns a character (a value between 0x00-0xFF).
  • The problem is that there are sets of characters X,Y,Z, ... where
    X!=Y, X!=Z, but strxfrm(X)==strxfrm(Y)==strxfrm(Z). In charset
    terminology, these characters have "the same weight" (let's call them a "weight group")

in latin1_swedish_ci: 114 characters have weight conflicts. They form 31 weight groups, size of the group varies between two members (19 groups) and ten (4 groups)

in latin1_general_ci: 56 characters have weight conflicts. They form 28 groups of two members each.

latin1_general_cs has no weight conflicts (we can just enable index_only for it).

Constructing restore_data

value <=> (mem_comparable_form, restore_data).

Let's take one character of the "value".
If its weight is unique, it can be restored from its mem-comparable form.

If its weight is shared with a set of characters $WEIGHT_GROUP, we can assign (statically) a number to each member of the set. The number can be stored in restore_data.

  • $WEIGHT_GROUP is usually small, so the number will only occupy a few bits.
  • by looking at restore_data, we can find its $WEIGHT_GROUP, and know how many
    bits (if any) are used to store the number of the value in the group.

Other 1-byte charsets

Some 1-byte charsets like latin1_german2_ci may map a single character into two bytes. (most of characters have 1-byte mem_comparable_form, but some have 2-byte). It looks like our approach could be extended to handle those, too.

@hermanlee
Copy link
Contributor Author

Comment by spetrunia
Monday Feb 02, 2015 at 18:15 GMT


Unicode

// our charsets guru is currently not available, but we've had a discussion about this before and I've took another look now.

Most important

  • utf_bin - Already handled
  • utf8_general_ci - the "simpler" collation, provides basic sorting
  • utf8_unicode_ci - more complex
  • utf8mb4 - ??

utf8_general_ci

Sorts about 64K characters, non-trivial sorting provided for 2816 characters
(AFAIU, "alphabets").

Basically, it extends 1-byte charsets approach into using multiple "pages".
There are 11 256-element pages that have non-trivial case conversions or sorting rules such that weight(X)!=X.
For other pages, weight(X) = two_byte_form(X).

Pages with non-trivial case conversions can be handled in the same way as was proposed for 1-byte charsets.

utf8_unicode_ci

This is more complex collation as it does things like Beta='ss' for German, etc.
We may have difficulties with fully supporting it, because some languages have rather complex rules.
OTOH, these languages are not that common, so for those we could just store the source character in the restore_data. This will double the used space.

lth added a commit that referenced this issue Jun 10, 2016
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Test Plan:
Manually change latest to `PRIMARY_FORMAT_VERSION_UNPACK_INFO` and run:
  mysqltest.sh --testset=RocksDB

Create database with old version. Recompile code with new version set, and see if it starts up and runs correctly.

Reviewers: hermanlee4, spetrunia, jkedgar

Reviewed By: jkedgar

Subscribers: vasilep, webscalesql-eng

Differential Revision: https://reviews.facebook.net/D58503
hermanlee pushed a commit that referenced this issue Jan 31, 2017
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Test Plan:
Manually change latest to `PRIMARY_FORMAT_VERSION_UNPACK_INFO` and run:
  mysqltest.sh --testset=RocksDB

Create database with old version. Recompile code with new version set, and see if it starts up and runs correctly.

Reviewers: hermanlee4, spetrunia, jkedgar

Reviewed By: jkedgar

Subscribers: vasilep, webscalesql-eng

Differential Revision: https://reviews.facebook.net/D58503
Differential Revision: https://reviews.facebook.net/D59469
VitaliyLi pushed a commit to VitaliyLi/mysql-5.6 that referenced this issue Feb 9, 2017
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Test Plan:
Manually change latest to `PRIMARY_FORMAT_VERSION_UNPACK_INFO` and run:
  mysqltest.sh --testset=RocksDB

Create database with old version. Recompile code with new version set, and see if it starts up and runs correctly.

Reviewers: hermanlee4, spetrunia, jkedgar

Reviewed By: jkedgar

Subscribers: vasilep, webscalesql-eng

Differential Revision: https://reviews.facebook.net/D58503
Differential Revision: https://reviews.facebook.net/D59469
@gunnarku gunnarku unassigned lth Apr 6, 2017
facebook-github-bot pushed a commit that referenced this issue Dec 23, 2019
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 9dec4e2
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Aug 12, 2020
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 9dec4e2
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Sep 9, 2020
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 9dec4e2
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Sep 16, 2020
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 9dec4e2
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Oct 5, 2020
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 9dec4e2
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Nov 11, 2020
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 9dec4e2
facebook-github-bot pushed a commit that referenced this issue Mar 8, 2021
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 3bb23231c78
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Aug 16, 2021
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 3bb23231c78
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Aug 30, 2021
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 3bb23231c78
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Aug 30, 2021
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 3bb23231c78
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Sep 1, 2021
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 3bb23231c78
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Sep 2, 2021
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469

fbshipit-source-id: 3bb23231c78
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jan 17, 2022
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Apr 26, 2022
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue May 20, 2022
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469
laurynas-biveinis pushed a commit to laurynas-biveinis/mysql-5.6 that referenced this issue Aug 11, 2022
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Mar 28, 2023
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jun 1, 2023
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469
inikep pushed a commit to inikep/mysql-5.6 that referenced this issue Jun 14, 2023
Summary:
This changes the PK storage format so that it can contain unpack_info.

Currently, the storage format looks like this:
  | null bits | records for non-packable or non-PK columns | checksum |

I am changing the format so that it looks like this:
  | null bits | unpack_info | records for non-packable or non-PK columns | checksum |

The `unpack_info` field looks exactly the same as the one in secondary keys. It is a one-byte tag, followed by two bytes of length information, followed by the actual unpack information.

Note that this field may be missing if none of the key columns have a make unpack function set.

The main change that needed to be done to support this is to have the `m_make_unpack_info_func` function be available in both `Rdb_field_packing` for `Rdb_key_def::pack_record` and `Rdb_field_encoder` for `ha_rocksdb::convert_record_to_storage_format`.

Note that this change isn't active since `PRIMARY_FORMAT_VERSION_UNPACK_INFO` is not the latest.

Reviewed By: jkedgar

Differential Revision: https://reviews.facebook.net/D59469
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants