List:Internals« Previous MessageNext Message »
From:Sergei Golubchik Date:July 16 2009 6:36pm
Subject:Re: is MySQL bug #44373 really a bug?
View as plain text  
Hi, Michael!

On Jul 16, Michael Widenius wrote:
> >> 
> >> Is the new bitmap a strict subset of the old one ? I remember
> >> discussions that NDB needs to know the bitmap before the scan
> >> starts (e.g. before index_init) because it sends it (bitmap) to
> >> other nodes, and we were talking about an optimization where MySQL
> >> could remove columns from a bitmap after the scan started - but the
> >> engine was not required to obey it, indeed, it's always ok to
> >> return more columns than what was requested. But even in this case
> >> column_bitmaps_signal() should've been called. Still a bug.
> 
> No, the new bitmap may be totally unrelated to the old one.
> 
> For example, MySQL may first do an ORDER by optimization and use a
> bitmap that only fetches the row id + what is in the ORDER BY part and
> then later it may fetch the whole rows.

Monty, you've missed the point. I'm talking about bitmap changes in the
middle of the scan. Like

 index_init
 index_read
 index_read
   ... bitmap change ...
 index_read
 index_read

for the ORDER BY it's one bitmap for the first scan, another bitmap for
the second. No problem here.
 
> >> If a new bitmap is not a strict subset of the old one then it's a
> >> much worse bug, and it probably would deliver incorrect query
> >> results (or worse) with ndb.
> 
> It's a not a bug; The interface is designed with the idea what the map
> can change any time in any way.  It shouldn't be hard to inform the
> NDB nodes for bitmap changes if this is a problem.

When a scan starts NDB sends the bitmap to the nodes and they start
sending the data back. If bitmap changes, it has to abort the current
scan (I presume) send new bitmap to the nodes and re-retrieve rows that
were already sent under the old bitmap but not yet consumed by the
server. You're right, it's not very hard. But it's expensive.
 
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
Thread
is MySQL bug #44373 really a bug?Zardosht Kasheff14 Jul
  • Re: is MySQL bug #44373 really a bug?Sergei Golubchik18 Jul
Re: is MySQL bug #44373 really a bug?Zardosht Kasheff15 Jul
  • Re: is MySQL bug #44373 really a bug?Michael Widenius16 Jul
    • Re: is MySQL bug #44373 really a bug?Brian Aker16 Jul
    • Re: is MySQL bug #44373 really a bug?Sergei Golubchik18 Jul
      • Re: is MySQL bug #44373 really a bug?Michael Widenius19 Jul