LevelDB storage engine development

You are viewing an old version of this article. View the current version here.

Items that are considered for development.

Use keys that are compared with memcpy()

Current way to compare keys (find the table DDL in the hash, then use ha_key_cmp()) is likely to be slow. Its only advantage is that keys are packed.

If we switched to keys that were comparable with memcpy(), it would be easier.

Making keys comparable

Falcon SE

Falcon did use memcmp() to compare index tuples. Looking into the source (it is available for download still), one can see the comparison being somewhere around:

void Index::makeKey(Field *field, Value *value, int segment, IndexKey *indexKey, bool highKey)
void Index::makeMultiSegmentKey(int count, Value **values, IndexKey *indexKey, bool highKey)
...
void IndexKey::appendNumber(double number)
^^ makes double numbers memcmp'able...

unfortunately, there is no single, isolated part of code that we could copy. (Or may be there is, but we were not able to find it yet).

Field::make_sort_key

Found this in the source:

  /**
    Writes a copy of the current value in the record buffer, suitable for
    sorting using byte-by-byte comparison. Integers are always in big-endian
    regardless of hardware architecture. At most length bytes are written
    into the buffer.

    @param buff The buffer, assumed to be at least length bytes.

    @param length Number of bytes to write.
  */
  virtual void make_sort_key(uchar *buff, uint length) = 0;

Looks like this is exactly what we needed?

Use table/index numbers as prefixes

Currently, keys are prefixed with

dbname.table_name$INDEX_NO\0

where INDEX_NO is one byte with "number of index plus one".

This prevents fast rename table. DROP TABLE also needs to delete all rows.

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.