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
given what is documented on
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
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:
Hauptsitz: MySQL GmbH, Radlkoferstr. 2, D-81373 München
Geschäftsführer: Kaj Arnö - HRB München 162140