From: Sergei Golubchik
Date: May 14 2009 10:09am
Subject: Re: Handling of keypart_map in custom storage engine
List-Archive: http://lists.mysql.com/internals/36685
Message-Id: <20090514100916.GB13840@janus.mylan>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi, Vyacheslav!

On May 13, Vyacheslav Akhmechet wrote:
> Hi,
> 
> When the server calles index_read and related functions, it passes
> keypart_map which indicates which parts of the key are present. I'm
> not completely sure how to handle the implementation of this - if the
> semantics of keypart_map are such that any of the bits may be set or
> unset, I don't know how an efficient implementation can be possible.
> 
> Suppose a given key has two parts, A and B, and I build an index on
> this key (by combining A and B in lexicographic order, or a similar
> technique). Now, suppose index_read is called, and part A is missing
> from the key. In this case the index is essentially useless - I need
> to do a full table scan. I don't see how one could implement an index
> to get around this.
> 
> Am I misunderstanding the purpose/semantics of keypart_map?

No, you are not. Btree indexes, indeed, cannot support this feature.
Bitmap indexes, I presume, can.

Anyway, at the moment keypart_map can only have full prefixes, if a bit
N is set all previous bits are set too.

You can even add an assert to your engine, like myisam does:

  /* only key prefixes are supported */
  DBUG_ASSERT(((keypart_map+1) & keypart_map) == 0);
 
Regards / Mit vielen Grüßen,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg@stripped>
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Engineer/Server Architect
/_/  /_/\_, /___/\___\_\___/  Sun Microsystems GmbH, HRB München 161028
       <___/                  Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring