Release notes for mysql-55-eb

In MySQL docs the terms "thread" and "connection" or "session" are often used interchangeably, when in fact "connection"/"session" is meant. This is not a big deal with the 1-1 connection-thread model, but gets confusing when the thread pool is used, and there is no 1-1 relationship anymore. I think it's good idea to mention this in release notes too.

Also for the release notes: the current thread pool implementation and PERFORMANCE_SCHEMA are not compatible.

It is currently impossible to use indexes on BLOB columns due to some limitations of the dynamic row format. Trying to create such an index will fail with the following error: "BLOB column '<name>' can't be used in key specification with the used table type".

The server needs to be built with -DWITH_LIBEVENT=bundled in order to have the thread pool option. No other value for this option is supported (e.g. it is possible to use only the bundled libevent library, not any installed on the system).

The various existing usage notes for dynamic VARCHAR in HEAP are in the long comment at the beginning of storage/heap/hp_dspace.c.

Comments from storage/heap/hp_dspace.c transformed to a user-readable form with some clarifications:

Dynamic row format for MEMORY tables, introduced in this release, is
used to store VARCHAR column values in a variable-length form, thus
helping to decrease memory footprint of those columns. The dynamic
format also adds support for BLOB columns to MEMORY tables, because
storing BLOB values in fixed length is impossible.

Unlike fixed row format, each column value in dynamic row format only
uses as much space as required. That is, for VARCHAR and BLOB values, up
to 4 bytes is used to store the actual value length, and then only the
necessary number of bytes is used to store the value.

Rows in dynamic format are represented internally by multiple memory
blocks, which means that a single row can consist of multiple blocks
organized into one set. Each row occupies at least one block, that is
there can be no multiple rows within a single block. Block size can be
configured when creating a table (see below).

For performance reasons, the MEMORY engine needs to keep all values for
columns used in indexes in the fixed format in the first block even if
dynamic format is used for the rest of row. This means it is better to
define such columns first in CREATE TABLE to allow other columns benefit
from dynamic format if it is used. This also sets a limitation on the
least possible block size (see notes about KEY_BLOCK_SIZE below).

Notes on how the choice between dynamic and fixed row formats is
performed by the MEMORY storage engine:

* if there is at least one BLOB/TEXT column in the table definition,
  dynamic format is used;

* if there are no BLOB/TEXT columns, and dynamic format was not
  explicitly requested by a user, fixed format is used;

* there are two CREATE TABLE options that can be used to request the
  dynamic row format to be used:

  - KEY_BLOCK_SIZE=<value> requests the dynamic format with the
  specified block size. Despite its name, the KEY_BLOCK_SIZE option
  refers to a block size used to store data rather then indexes. The
  reason for this is that an existing CREATE TABLE option is reused
  without introducing new ones. The MEMORY engine checks whether the
  specified block size is large enough to keep all key column values. If
  it is too small, table creation will abort with an error;

  - ROW_FORMAT=DYNAMIC requests the dynamic format with the default
  block size (256 bytes);

* even if the dynamic row format was explicitly requested with one of the
  above options, the MEMORY engine checks if using the dynamic format
  provides any space saving benefits as compared to the fixed one. If
  the fixed row length is less than the dynamic block size (plus the
  dynamic row overhead), the MEMORY engine will revert to the fixed
  format as it is more space efficient in such a case;

* even if the dynamic row format was explicitly requested, the MEMORY
  engine will revert to the fixed format if there are no variable-length
  columns in the table;

Addendum to the last item from the previous comment:

"* even if the dynamic row format was explicitly requested, the MEMORY
  engine will revert to the fixed format if there are no variable-length
  columns in the table;"

should read

"* even if the dynamic row format was explicitly requested, the MEMORY
  engine will revert to the fixed format if there are no variable-length
  columns in the table, or VARCHAR fields are declared with length 31 or less;"