List:Falcon Storage Engine« Previous MessageNext Message »
From:Vladislav Vaintroub Date:February 16 2009 10:07pm
Subject:RE: Patch for bug#42208
View as plain text  

> -----Original Message-----
> From: Jim Starkey [mailto:jstarkey@stripped]
> Sent: Monday, February 16, 2009 10:46 PM
> To: Vladislav Vaintroub
> Cc: Lars-Erik.Bjork@stripped; 'FalconDev'
> Subject: Re: Patch for bug#42208
> 
> 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.

Well, encoding scheme I propose has no #3 , i.e there is a difference
between key of 0 length and 0x00 key of length 1. And yes, this breaks in
multi-segment keys, but multi-segment keys are "advanced".


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

You might be right from practical point of view (zero length , 0x00 who
cares) but our QA is not practical, rather standard-oriented (whatever
standard may be, ANSI or MySQL common practice). If doing something to
please QA  does not cost  pain (like here, adding single byte in extremely
rare circumstances), I believe we should go for it.

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


Thread
Patch for bug#42208Lars-Erik Bjørk16 Feb
  • RE: Patch for bug#42208Vladislav Vaintroub16 Feb
    • RE: Patch for bug#42208Vladislav Vaintroub16 Feb
      • Re: Patch for bug#42208Jim Starkey16 Feb
        • RE: Patch for bug#42208Vladislav Vaintroub16 Feb
    • Re: Patch for bug#42208Jim Starkey16 Feb
      • RE: Patch for bug#42208Vladislav Vaintroub16 Feb
      • Re: Patch for bug#42208Lars-Erik Bjørk17 Feb
        • Re: Patch for bug#42208Kevin Lewis17 Feb
          • Re: Patch for bug#42208Ann W. Harrison18 Feb
            • Re: Patch for bug#42208Ann W. Harrison18 Feb
              • Re: Patch for bug#42208Ann W. Harrison18 Feb
                • Re: Patch for bug#42208Kevin Lewis18 Feb
                  • Re: Patch for bug#42208Ann W. Harrison18 Feb
                    • Re: Patch for bug#42208Kevin Lewis18 Feb
          • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
            • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
              • Re: Patch for bug#42208Kevin Lewis18 Feb
                • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
                  • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
              • Re: Patch for bug#42208Jim Starkey18 Feb
                • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
                  • Re: Patch for bug#42208Jim Starkey18 Feb
                    • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
                      • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
            • Re: Patch for bug#42208Ann W. Harrison18 Feb
              • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
                • Re: Patch for bug#42208Jim Starkey18 Feb
                  • Re: Patch for bug#42208Ann W. Harrison18 Feb
                    • Re: Patch for bug#42208Ann W. Harrison18 Feb
                • Re: Patch for bug#42208Ann W. Harrison18 Feb
                  • RE: Patch for bug#42208Vladislav Vaintroub18 Feb
                    • Re: Patch for bug#42208Ann W. Harrison18 Feb
                    • Re: Patch for bug#42208Kevin Lewis18 Feb
                      • Re: Patch for bug#42208Ann W. Harrison18 Feb
      • Re: Patch for bug#42208MARK CALLAGHAN17 Feb
  • Re: Patch for bug#42208Jim Starkey16 Feb