Hi!
>>>>> "Zardosht" == Zardosht Kasheff <zardosht@stripped> writes:
Zardosht> Hello all,
Zardosht> As best as I understand, a handler mostly does reads by performing the
Zardosht> following sequence of operations (not including rnd_XXX functions):
Zardosht> - call handler::index_init
Zardosht> - perform a bunch of handler::index_XXX calls
Zardosht> - call handler::index_end
Zardosht> I am wondering what other handler operations may occur in between
Zardosht> index_init and index_end that may block a handler::index_XXX call.
You can also get update/delete/insert calls betwen the init/end calls.
What do you mean with 'block' a call here ?
Zardosht> For instance, in the case of deletes and updates, I know that the
Zardosht> handler that performs an index_XXX call may then perform
Zardosht> handler::delete_row or handler::update_row. So, a subsequent call to
Zardosht> handler::index_XXX may not occur until the delete_row or update_row is
Zardosht> complete.
Zardosht> Are there any other cases where the sequence of index_XXX calls may be
Zardosht> blocked? For instance, is there a chance that some other handler's
Zardosht> work may block execution of and index_XXX call? Can joins or index
Zardosht> merges do such a thing?
As part of select Joins/merges will only do read calls. However when
doing multi-table updates/deletes these will be mixed with update &
delete calls.
Regards,
Monty
