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
--
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html
Hauptsitz: MySQL GmbH, Radlkoferstr. 2, D-81373 München
Geschäftsführer: Kaj Arnö - HRB München 162140
