On Tue, Nov 24, 2009 at 05:43:40PM +0200, Vladimir Kolesnikov wrote:
> I have finished work on all issues but one. And here I need some
> input from Drizzle developers. The problem is that for enums
> reported key size is not consistent with reported key type:
>
> inline uint32_t get_enum_pack_length(int elements)
> {
> return elements < 256 ? 1 : 2;
> }
>
> But at the same time:
>
> enum ha_base_keytype Field_enum::key_type() const
> {
> switch (packlength)
> {
> default: return HA_KEYTYPE_BINARY;
> case 2: assert(1);
> case 3: assert(1);
> case 4: return HA_KEYTYPE_ULONG_INT;
> case 8: return HA_KEYTYPE_ULONGLONG;
> }
> }
Well... this is nice and interesting.
In MySQL 6:
enum ha_base_keytype Field_enum::key_type() const
{
switch (packlength) {
default: return HA_KEYTYPE_BINARY;
case 2: return HA_KEYTYPE_USHORT_INT;
case 3: return HA_KEYTYPE_UINT24;
case 4: return HA_KEYTYPE_ULONG_INT;
case 8: return HA_KEYTYPE_ULONGLONG;
}
}
So indeed we have possibly ended up with a bug here....
Are we wanting to continue with saving some bytes and doing 2 bytes
indexed?
If we just do 4 all the time then it does mean you can effectively
infinitely ALTER the table to have more values.... which is where i'm
leaning - towards having enum just being a 4byte int.
> This problem might affect other engines and it might be not easy to
> reproduce - surprisingly the memory is usually zeroed right after
> the key value, unless there was a heavy load before the test.
Interesting that it hasn't been picked up... do we not have that in a
test?
--
Stewart Smith
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
