Hi!
On Oct 16, Hagen H?pfner wrote:
> Dear List,
>
> what is the MAX_BLOCK_SIZE that is stored in the MYI-Header
>
> uint i, keys= (uint) state->header.keys,
> key_blocks=state->header.max_block_size;
>
> In the internals-documentation there is the example that this value
> might be 0x01 ... but what does this mean? I know that key are written
> in a page/block-wise manner but this does not help for intepreting the
> block size.
In mi_open() there's the following line:
memcpy((char*) share->state.key_del,
(char*) key_del, (sizeof(my_off_t) *
share->state.header.max_block_size));
where key_del[] is defined as
my_off_t key_del[MI_MAX_KEY_BLOCK_SIZE];
and MI_MAX_KEY_BLOCK_SIZE is
#define MI_MAX_KEY_BLOCK_SIZE (MI_MAX_KEY_BLOCK_LENGTH/MI_MIN_KEY_BLOCK_LENGTH)
so apparently share->state.header.max_block_size is block size measured
in MI_MIN_KEY_BLOCK_LENGTH units.
Now, it's used in mi_state_info_write() as you quoted:
uint i, keys= (uint) state->header.keys,
key_blocks=state->header.max_block_size;
and later
for (i=0; i < key_blocks; i++)
{
mi_sizestore(ptr,state->key_del[i]); ptr +=8;
}
MYI file has block structure, where blocks cane have different sizes
(though a size is a multiple of MI_MIN_KEY_BLOCK_LENGTH).
When a key block is deleted from btree it's added to 'deleted' list
where it will be picked up later for reusal.
Apparently, state->key_del[i] is the head of 'deleted' list for blocks
of the size (i+1)*MI_MIN_KEY_BLOCK_LENGTH
Then state->header.max_block_size is the max keypage size as a multiple
of MI_MIN_KEY_BLOCK_LENGTH, in this MYI file.
At least this is how I read the above :)
> My second question is ... where (source code) can I find the possible
> collations (languages) supported by MySQL? There is a Byte in the
> MYI-header. So, I assume you might have more than one language ;-)
strings/ctype-*.c - look for CHARSET_INFO structures.
> All the best,
>
> Hagen
>
> BTW: in the version of the internals documentation that I am using, you
> have included the following example:
>
> options 2 00 02 HA_OPTION_COMPRESS_RECORD
> etc.
> But if I look into source code, then I can find
> #define HA_OPTION_PACK_KEYS 2
>
> and
>
> #define HA_OPTION_COMPRESS_RECORD 4
>
> Was there a change in the current version or is it just a inconsitency?
I doubt it was ever changed.
Most probably the text means:
field name value in the file in question contains
..
options 2 00 02 HA_OPTION_COMPRESS_RECORD
etc.
That is, the field 'options' contains values like
HA_OPTION_COMPRESS_RECORD, etc. And in this particular file it's value
is 2.
I'm not the author of the text, but I think he didn't mean that the
value of HA_OPTION_COMPRESS_RECORD is 2.
Regards,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer
/_/ /_/\_, /___/\___\_\___/ Kerpen, Germany
<___/ www.mysql.com
