Re: what can a sequence of handler::index_XXX be interrupted by?

For the last case, where we have:
>    handlers[0]->index_XXX();
>    handlers[1]->index_XXX();
>    handlers[2]->index_XXX();
>    handlers[0]->index_XXX();
>    handlers[0]->index_XXX();
>    handlers[1]->index_XXX();

I assume each of the handlers share the same thd object? So if I check
the thd object for each of the handlers, I will get the same one?

I guess here is another question. Is there any way for a handler with
some thd object be blocked from executing until some operation with
ANOTHER thd finishes. For instance, in the above example, handlers[1]
cannot execute until handlers[0] performs its index_XXX function, but
(I hope) they have the same thd.

On Tue, Jul 26, 2011 at 12:46 PM, Sergey Petrunya <[email protected]> wrote:
> On Tue, Jul 26, 2011 at 09:42:58AM -0400, Zardosht Kasheff wrote:
>> As best as I understand, a handler mostly does reads by performing the
>> following sequence of operations (not including rnd_XXX functions):
>>  - call handler::index_init
>>  - perform a bunch of handler::index_XXX calls
>>  - call handler::index_end
>>
>> I am wondering what other handler operations may occur in between
>> index_init and index_end that may block a handler::index_XXX call.
>>
>
> When SQL layer needs rowids for rows it is reading, it will call
> handler->position() after each call that has returned a row.
>
> There can also be unlock_row() call for each read row, about which I can't tell
> much off the top of the head.
>
>>
>> For instance, in the case of deletes and updates, I know that the
>> handler that performs an index_XXX call may then perform
>> handler::delete_row or handler::update_row. So, a subsequent call to
>> handler::index_XXX may not occur until the delete_row or update_row is
>> complete.
>>
>> Are there any other cases where the sequence of index_XXX calls may be
>> blocked? For instance, is there a chance that some other handler's
>> work may block execution of and index_XXX call? Can joins or index
>> merges do such a thing?
>
> Join runtime does table scans (or index scans, or index lookups, depending
> on the used access method) multiple times, so its handler call pattern will
> be the same
>
>>  - call handler::index_init
>>  - perform a bunch of handler::index_XXX calls             [idx-pattern]
>>  - call handler::index_end
>
> repeated multiple times.
> There are some cases where the above index_init() ... index_end() pattern will
> alternate with "rnd_init(); while(..) {rnd_next();} rnd_end(); pattern, but
> each of the pattern will remain un-broken.
>
> index_merge/sort-union has this call pattern:
>
>  for each merged index I
>  {
>    run pattern [idx-pattern] for index I, with position() call after each
>      record read;
>  }
>  h->rnd_init();
>  while(...) {
>    h->rnd_pos();
>  h->rnd_end();
>
> .. which is not that different from what other access methods do.
>
> index_merge/intersection and index_merge/union (called as ROR-intersection an
> ROR-union in the code) have a rather peculiar call patterns, as they need to run
> multiple index scans simultaneously. They do it as follows:
>
>  for each merged index I except the first one
>  {
>    handlers[i]= handler->clone();
>    handlers[i]->index_init(I);
>  }
>
>  /*
>    Now, simultaneously run [idx-pattern] for each of handlers[i]. That is,
>    index_merge code will repeatedly call handlers[k]->index_XXX()  where
>    k will change in a seemingly random fashion,e.g. you will see calls like
>    this:
>
>    handlers[0]->index_XXX();
>    handlers[1]->index_XXX();
>    handlers[2]->index_XXX();
>    handlers[0]->index_XXX();
>    handlers[0]->index_XXX();
>    handlers[1]->index_XXX();
>    ...
>
>  */
>  /* it all will end with: */
>  {
>    handlers[i]->index_end();
>    handlers[i]->close();
>    delete handlers[i];
>  }
>
> Hope this makes it clear.
>
> BR
>  Sergey
> --
> Sergey Petrunia, Software Developer
> Monty Program AB, http://askmonty.org
> Blog: http://s.petrunia.net/blog
>

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/[email protected]