maria-developers team mailing list archive

[Sergei Petrunia <psergey@xxxxxxxxxxxx>]

On Fri, Apr 27, 2012 at 01:31:08PM +0400, Elena Stepanova wrote:
> Hi Sergey,
>
> OK, I will start working on this.
>
> > Before this WL, the code that produced EXPLAIN output
> > - Required that optimizer produces a slightly different structures
> > when EXPLAIN is running
> > - Did destructive modifications to the query plan
>
> Does this mean that the traditional EXPLAIN (preceding a statement or  
> subsequent to it) is also affected?
>
Yes. I've changed regular EXPLAIN code so that it can be ran multiple times.
That way, traditional EXPLAIN is affected.

There is one known difference, currently only documented in this e-mail (will
forward it):
  Date: Sat, 27 Aug 2011 10:14:13 +0400
  From: Sergey Petrunya <psergey@xxxxxxxxxxxx>
  To: maria-developers@xxxxxxxxxxxxxxxxxxx
  Subject: [Maria-developers] MWL#182: a problem select_type column,
          SIMPLE vs PRIMARY


> By the way, s there any standard way of naming the new EXPLAIN, as  
> opposed to the old EXPLAIN? (e.g. Online EXPLAIN? Asynchronous? Running?  
> Parallel?)
> This is just to simplify further talks.

We call it "SHOW EXPLAIN", following the SQL syntax. Nobody has made an
explicit decision on the "official" way to name it, but it looks like this name
will stick.

> Regards,
> /E
>
>
> On 4/27/2012 9:13 AM, Sergei Petrunia wrote:
>> Hi Elena,
>>
>> I need testing for MWL#182 SHOW EXPLAIN.
>>
>> The code is here: lp:~maria-captains/maria/5.3-show-explain2 (note the '2' at
>> the end)
>>
>> The branch is currently based on 5.3, although will move to 5.5 soon (I suppose
>> this doesn't cause any problems for testing).
>>
>> Currently, I can think of two things that need testing:
>>
>> === "Asynchronous Procedure Call" module ===
>> This is a module that allows one thread to schedule a call in the other thread,
>> and wait until the call has been invoked.
>>
>> Suggested way to test:
>> - run a set of queries that look at each other with "SHOW EXPLAIN FOR<thread>"
>>    statements.
>> - have some "victim" threads which run long queries, and have "attacker"
>>    threads which submit a lot of "SHOW EXPLAIN FOR<victim_thread>" queries.
>>
>> === On-the-fly EXPLAIN printing functionality ===
>> Before this WL, the code that produced EXPLAIN output
>> - Required that optimizer produces a slightly different structures when EXPLAIN
>>    is running
>> - Did destructive modifications to the query plan (that is, it was not possible
>>    to call these functions two times to get two EXPLAIN outputs for the same
>>    planned query)
>>
>> Suggested way to test:
>> - Run various complicated queries, with UNIONs, JOINs, etc.
>> - While they are running, do SHOW EXPLAIN FOR command for them, expecting
>>    it to crash or produce nonsensical output at some point.
>>    If SHOW EXPLAIN crashes, the crash report will show the query it was trying
>>    to obtain the EXPLAIN for.
>>
>> My current suggestion is to use some "runner" threads to run the queries and
>> use another set of threads to hit the "runner" threads with SHOW EXPLAIN
>> request.
>>
>> When creating tests in mysql-test/t/show_explain.test, I made a framework that
>> allows to stop query execution at some particular point and then wait until
>> some number of SHOW EXPLAIN requests were arrived and served.
>>
>> This requires insertion of "probes" into the source code, though.
>>
>> Perhaps, we could use something like that for your testing: to have the query
>> pause at some "interesting" points and wait for SHOW EXPLAIN requests to arrive
>> and be served.  I wasn't able to come up with any intelligent way to find
>> interesting point though, so this is still just an idea.
>>
>> BR
>>   Sergei

-- 
BR
 Sergei
-- 
Sergei Petrunia, Software Developer
Monty Program AB, http://askmonty.org
Blog: http://s.petrunia.net/blog