Re: Patch for bug#42208

[Lars-Erik Bjørk]

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.
>