[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mysql-internals
Subject:    Re: what does "index map: N" mean?
From:       Paul DuBois <paul () mysql ! com>
Date:       2007-08-30 12:35:54
Message-ID: p06240852c2fc6a08da7e () [192 ! 168 ! 1 ! 128]
[Download RAW message or body]

At 2:20 PM +0200 8/30/07, Hartmut Holzgraefe wrote:
>Baron Schwartz wrote:
>>Jay Pipes wrote:
>>>This is very interesting.  Sergey, is this engine-agnostic?  I 
>>>know that Falcon has sparse bitmap indexing (already?) but I did 
>>>not know if other engines support the concept (if not, are we 
>>>"emulating" it in the optimizer?)
>>>
>>>Baron, which engine are you testing against?
>>
>>I don't think it's the same thing as bitmap indexing -- as I 
>>understand it, it's a bitmap that says which indexes which could 
>>help a join between two tables, i.e. a cryptic way of listing 
>>indexes.  At each row in table N, the server looks at the indexes 
>>in table N+1 and decides which one might help find matching rows 
>>for the current values.
>>
>>I think this isn't the same thing as a bitmap index, which I 
>>actually don't really understand.  But maybe this is an "emulation" 
>>of bitmap indexes.
>
>given what is documented on
>
>   http://dev.mysql.com/doc/refman/5.0/en/explain.html
>
>it looks as if it is just showing a column bitmap for
>the utilized index:
>
>   # range checked for each record (index map: N)
>
>   MySQL found no good index to use, but found that some of indexes might
>   be used after column values from preceding tables are known. For each
>   row combination in the preceding tables, MySQL checks whether it is
>   possible to use a range or index_merge access method to retrieve rows.
>   This is not very fast, but is faster than performing a join with no
>   index at all. The applicability criteria are as described in Section 6.2.5,
>   "Range Optimization", and Section 6.2.6, "Index Merge Optimization",
>   with the exception that all column values for the preceding table are
>   known and considered to be constants.
>
>looks as if the documentation needs to go into more detail here


And when a dev supplies the information that should be added,
we'll be happy to do so.

-- 
Paul DuBois, MySQL Documentation Team
Madison, Wisconsin, USA
MySQL AB, www.mysql.com

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=mysql-internals@progressive-comp.com

[prev in list] [next in list] [prev in thread] [next in thread]