Re: bk commit - 6.0-falcon tree (istruewing:1.2563) BUG#26827

Hi!

On Jun 22, Ingo Strüwing wrote:
> Hi Sergei,
>
> thanks for the explanations. Please see below for more questions.
>
> Sergei Golubchik wrote:
> > Hi!
> >
> > On Jun 21, Ingo Strüwing wrote:
> ...
> >> Do you suggest that we do bitmap_set_all(read_set); handler= clone();
> >> rnd_pos(); delete handler; to retrieve a full row? Do that wherever we
> >> saw a duplicate key error? Or do it in handler::print_error()?
> >
> > basically yes. few thoughts:
> > - bitmap_set_all can be done after clone
> > - after bitmap_set_all you need to call column_bitmaps_signal() on the
> > cloned handler
> > - you need to clone only once, on the first duplicate key error
> > - you don't need bitmap_set_all, that is, no need to set ALL bits, it's
> > enough to set only bits for fields that are part of the UNIQUE key.
> > But as we don't expect duplicate key error to happen many times, this
> > optimization isn't important.
> > - in any case all the above can be skipped if the necessary bit is
> > already set in read_set. That is, for MyISAM, HEAP, and other storage
> > engines that always read the full row the above should not be executed
> > at all.
>
> I still do not know, where to implement it: Do that wherever we saw a
> duplicate key error? Or do it in handler::print_error()?

I'd prefer it to be done wherever we saw a first duplicate key error, in sql_update.cc. If possible.

Another optimization - you only need to clone if the main handler will need to continue the scan - that is, if it's UPDATE IGNORE. Normally update is aborted on the first error, so there's no need to preserve the cursor.  

> Why do we need that clone at all? When we take position() and do
> rnd_pos() on it, do we modify the current position?

No.

> Is the cursor disturbed by it?

Yes, it may be. A cursor may be more than a position. For example, if it's an index scan, in MyISAM the cursor includes lastkey value. In NDB the scan is done on all nodes asynchronously. The cursor includes the current position on every node.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.mysql.com Links announce benchmarks bugs certification cluster commits dotnet gui-tools internals java maxdb myodbc mysql mysqldoc packagers perl plusplus replication win32 Request more information about Pantek

> The importance of the question is made by the fact that we need to do
> the same in the partition handler when an update moves a record from
> one partition to another. ha_partitiom::update_row() calls
> handler::write_row() in this case and must provide a complete record.

In this case you don't need to clone at all. As I wrote above "in any case all the above can be skipped if the necessary bit is already set". That is, partition handler needs the complete record, so it sets all bits in read_set. On the duplicate key, MySQL checks the read_set and notices that the field it needs for the error message is present in the record image, so it can generate an error message right away. Re-reading the row (with rnd_pos) is only necessary if a field is missing in read_set. And a clone is only necessary if we want to continue the scan after issuing the error message (UPDATE IGNORE).

Multi-table update, by the way, is often resolved via temporary table, all positions are stored there, then MySQL does rnd_pos only. In this case there's no cursor to preserve, so even in UPDATE IGNORE case we don't need to clone.

Regards / Mit vielen Grüssen,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik 
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Developer
/_/  /_/\_, /___/\___\_\___/  MySQL GmbH, Radlkoferstr. 2, D-81373 München
       <___/                  Geschäftsführer: Kaj Arnö - HRB München 162140

-- 
MySQL Code Commits Mailing List
For list archives: 
http://lists.mysql.com/commits
To unsubscribe:    
http://lists.mysql.com/commits?unsub=lists@pantek.com