re: what can a sequence of handler::index_XXX be interrupted by?
Michael Widenius <[email protected]>
| Newsgroups | gmane.comp.db.mysql.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi! >>>>> "Zardosht" == Zardosht Kasheff <[email protected]> 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 -- MySQL Internals Mailing List For list archives: http://lists.mysql.com/internals To unsubscribe: http://lists.mysql.com/[email protected]