From: Lars-Erik Bjørk
Date: February 17 2009 8:13am
Subject: Re: Patch for bug#42208
List-Archive: http://lists.mysql.com/falcon/532
Message-Id: <499A71B0.2020006@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: 7BIT

Ok, so we probably don't want to do the caching after all then? Does 
anyone else have an opinion on how to proceed on this? Do we agree on 
any best approach?

/Lars-Erik

Jim Starkey wrote:
> Vladislav Vaintroub wrote:
>> Hi Lars-Erik,
>> I wonder if adding 0x00 to the (binary) string values that already start
>> with 0x00 would not be less works that modifying index walker etc. This
>> looks like huge amount of work you have done (good) but I wonder if 
>> there is
>> a good reason for it. Assuming (binary) strings that start with 0x00 are
>> really seldom, prepending 0x00 to a key after a check is not going to 
>> be an
>> expensive operation. And that makes NULL *really* different from 
>> other index
>> values. And that allows maybe in some distant future index-only 
>> access, so
>> you can answer "is null/is not null" without extra accessing the 
>> record and
>> this is a real performance advantage.
>>
>>   
> Why do you want to do that?  Is the following sufficient:
>
>   1. A null is represented as either a zero length key or a missing
>      segment in a multi-segment key.  This collates lowest.
>   2. A zero length binary key is represented by a single byte of zero.
>   3. A binary key with a single zero byte is indistinquishable from a
>      zero length (but non-null) key
>   4. A binary key with a leading zero byte and a subsequent non-zero
>      byte will collate about #2 and #3.
>
> I don't think we really care about the ordering of a non-null, zero 
> length key and and all zero binary key.  I don't think anyone else 
> should, either.
>