Re: Patch for bug#42208

[Jim Starkey]

Vladislav Vaintroub wrote:
>> -----Original Message-----
>> From: Jim Starkey [mailto:jstarkey@stripped]
>> Sent: Wednesday, February 18, 2009 3:50 PM
>> To: Vladislav Vaintroub
>> Cc: Kevin.Lewis@stripped; 'Lars-Erik Bjørk'; 'FalconDev'
>> Subject: Re: Patch for bug#42208
>>
>> It breaks all existing index code.  The entire structure of Falcon
>> indexes is that the index navigation code treats all keys as naturally
>> collated byte arrays.
>> Your scheme doesn't have that property, so it would be a total redesign
>> and rewrite.  Aside from that, your scheme significantly increases the
>> code of key comparison.  Btrees, you know, are comparison intensive, so
>> your scheme would be substantially slower.
>>
>>     
>
>
> Jim, you're  sure that this does not work. can you please construct an
> example where this scheme does not work, specifically Where it breaks
> "natural collation"? 2 keys that would sort in RUN scheme differently than
> in this scheme? I would not have mentioned it, if the entire structure of
> Adabas/Tamino  indexes where it was first implemented was so  that the index
> navigation code treats all keys as naturally collated byte arrays. Exactly
> as Falcons.
>
> 0 (0x1 0x0)  < 1 (0x1 0x01) < any other byte when compared naturally in this
> encoding.
>
>   
No, Vlad.  I'm not sure that it doesn't work.  The essence of the scheme is:

    * Keys of equal length compare naturally
    * A shorter key (actually the separator byte) will alway compare
      below a longer key, also naturally

At face value, it looks like a better way to handle keys.  There is some 
padding (relatively little since we truncate trailing zeros on numbers 
and zero bytes don't normally occur in strings), but less that our 
current scheme.

I'd like to think about it some more, but I think the idea has real 
merit.  Thanks for being so pugnacious. 


-- 
Jim Starkey
President, NimbusDB, Inc.
978 526-1376