List:Internals« Previous MessageNext Message »
From:Venu Kalyan Date:April 23 2010 6:18am
Subject:Re: HA_EXTRA_WRITE_CAN_REPLACE flag
View as plain text  
Small correction..

On Thu, Apr 22, 2010 at 11:11 PM, Venu Kalyan <mydb08@stripped> wrote:
> Hi Zardosht
>
> Someone can correct me if am mistaken.. but here is my understanding:
>
> - On plain INSERT (or LOAD DATA .. IGNORE..), duplicates are always
> error-ed out, provided storage engine returned HA_ERR_FOUND_DUPP_KEY
> - On REPLACE statements (or LOAD DATA .. REPLACE..or ON DUPLICATE
> KEY), engine first sets the flags HA_EXTRA_WRITE_CAN_REPLACE and
> HA_EXTRA_IGNORE_DUP_KEY  using ::extra()
>  - If storage engine finds a duplicate match, then it should return
> HA_ERR_FOUND_DUPP_KEY by keeping the error key position
>  - Now engine gets the error key position by calling info::HA_STATUS_ERRKEY
>  - Once it gets the key position, then it reads the duplicate row
> values by doing an index scan on that key
>  - Now it builds the old row (index read returned) and new row (from
> replace command) and then calls the update_row function by passing
> both old_row and new_row; and storage engine can take appropriate
> action
>  - If there is no duplicate; then engine simply commits the change
>
> If one uses ON DUPLICATE KEY; then the new_row from case #2 changes;
> but the same logic applies (engine also will not set
> HA_EXTRA_WRITE_CAN_REPLACE as that only for replace cases, not sure
> why as the logic is more or less the same)
>
> Also; before committing or posting index read; the engine resets both
> the flags (HA_EXTRA_NO_IGNORE_DUP_KEY, HA_EXTRA_WRITE_CANNOT_REPLACE)
>
> So; storage engine simply can't do an inline replace on write_row
> call....as that violates the interface semantics; but may be one day
> we can expect replace_row; so that it makes sense not to make two
> different calls to storage engine and storage can also make efficient
> inline replace as it can do this in first place itself without any
> buffering overhead (that's why storage engine should watch for this
> flags and take appropriate action during the index traversal; so that
> next call to replace is not expensive to find the last read row,
> innodb keeps a write lock on the row during write_row call when
> HA_EXTRA_WRITE_CAN_REPLACE is passed on )

InnoDB, Its other way, as there is no reason...check the file row/row0ins.c

Thanks
Venu
Thread
HA_EXTRA_WRITE_CAN_REPLACE flagZardosht Kasheff22 Apr
  • Re: HA_EXTRA_WRITE_CAN_REPLACE flagVenu Kalyan23 Apr
    • Re: HA_EXTRA_WRITE_CAN_REPLACE flagVenu Kalyan23 Apr
  • Re: HA_EXTRA_WRITE_CAN_REPLACE flagKonstantin Osipov23 Apr
    • Re: HA_EXTRA_WRITE_CAN_REPLACE flagKonstantin Osipov23 Apr
Re: HA_EXTRA_WRITE_CAN_REPLACE flagZardosht Kasheff23 Apr
Re: HA_EXTRA_WRITE_CAN_REPLACE flagZardosht Kasheff23 Apr
  • Re: HA_EXTRA_WRITE_CAN_REPLACE flagVenu Kalyan23 Apr
Re: HA_EXTRA_WRITE_CAN_REPLACE flagZardosht Kasheff24 Apr