List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:July 19 2009 5:38pm
Subject:Re: is MySQL bug #44373 really a bug?
View as plain text  
Hi!

>>>>> "Sergei" == Sergei Golubchik <serg@stripped> writes:

<cut>

>> 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.

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

Sergei>  index_init
Sergei>  index_read
Sergei>  index_read
Sergei>    ... bitmap change ...
Sergei>  index_read
Sergei>  index_read

Sergei> for the ORDER BY it's one bitmap for the first scan, another bitmap for
Sergei> the second. No problem here.

Agree, the above bitmap change shouldn't happen; Sorry for the
misunderstanding.

<cut>

Sergei> When a scan starts NDB sends the bitmap to the nodes and they start
Sergei> sending the data back. If bitmap changes, it has to abort the current
Sergei> scan (I presume) send new bitmap to the nodes and re-retrieve rows that
Sergei> were already sent under the old bitmap but not yet consumed by the
Sergei> server. You're right, it's not very hard. But it's expensive.

Thanks for the explanation. Agree that this is something that the
engine shouldn't have to do.

Regards,
Monty
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