From: MARK CALLAGHAN Date: May 14 2009 4:36pm Subject: Re: Handling of keypart_map in custom storage engine List-Archive: http://lists.mysql.com/internals/36691 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, May 14, 2009 at 9:23 AM, Sergei Golubchik wrote: > Hi, MARK! > > On May 14, MARK CALLAGHAN wrote: >> On Thu, May 14, 2009 at 3:09 AM, Sergei Golubchik wrote: >> > On May 13, Vyacheslav Akhmechet wrote: >> >> >> >> 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. >> >> Btrees can and do support index scans in this case. Check out index >> skip scan in Oracle. >> http://www.google.com/search?q=index+skip+scan > > Yes, right. > In btree you can do an index scan, but it won't be a range as with a > prefix key. > > Thanks for correcting me. No, now I understand. In the context of calls to the index scan methods in handler.h, btree cannot support this. My statement ignored that context. But speaking about index skip scan and bitmap indexes, when do we get support for them? There is some support in the optimizer for index-or and index-and. Is there any chance that will be expanded to support more complex predicates and costs that make bitmap indexes interesting? -- Mark Callaghan mdcallag@stripped