From: Jorgen Loland
Date: January 14 2011 12:23pm
Subject: Re: bzr commit into mysql-next-mr-bugfixing branch (jorgen.loland:3247)
 WL#4800
List-Archive: http://lists.mysql.com/commits/128734
Message-Id: <4D30403D.9020906@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Guilhem,

Thank you for the review. New commit on the way.

On 01/11/2011 02:38 PM, Guilhem Bichot wrote:
> Hello Jorgen,
>
> As you found out, in the previous review, three of my comments can be
> ignored.
> I made a new review of the latest commit, please find below some more
> comments.
>
> Jorgen Loland a écrit, Le 05.01.2011 14:48:
>> #At
>> file:///export/home/jl208045/mysql/wl4800/mysql-next-mr-opt-backporting-wl4800-range-subselect/
>> based on revid:guilhem@stripped
>>
>> 3247 Jorgen Loland 2011-01-05
>> WL#4800: Optimizer trace/debugger
>> Fix tracepoints so that all mtr test cases can be traced without JSON
>> syntax errors.
>> Added DYNAMIC_RANGE and REPEATED_SUBSELECT tracing features to
>> avoid repeated tracing of range analysis and execution, respectively,
>> of subselects.
>> @ sql/item_subselect.cc
>> Added Item_subselect::executed_before used to avoid tracing of
>> subquery execution when this happens repeatedly for each record
>> in outer select.
>> @ sql/item_subselect.h
>> Added Item_subselect::executed_before used to avoid tracing of
>> subquery execution when this happens repeatedly for each record
>> in outer select.
>> @ sql/opt_range.cc
>> Add tracepoints to range optimizer
>> @ sql/sql_select.cc
>> Add tracepoints to range optimizer
>>
>> modified:
>> mysql-test/r/mysqld--help-notwin.result
>> mysql-test/r/optimizer_trace2.result
>> mysql-test/r/optimizer_trace_charset.result
>> mysql-test/r/optimizer_trace_no_prot.result
>> mysql-test/r/optimizer_trace_ps_prot.result
>
> this ps_prot.result has not been updated enough, test fails. Suggestion
> for next commit: comparing ps_prot.result and no_prot.result to see
> whether some oddity has appeared.
>
>> === modified file 'mysql-test/r/optimizer_trace_range.result'
>> --- a/mysql-test/r/optimizer_trace_range.result 2011-01-03 20:36:18 +0000
>> +++ b/mysql-test/r/optimizer_trace_range.result 2011-01-05 13:48:15 +0000
>> +EXPLAIN SELECT STRAIGHT_JOIN * FROM t1, t2 +WHERE t1.key1=t2.key1a
>> AND t1.key2 > 1020 {
>> "steps": [
>> {
>
> In this trace we have empty "semijoin_strategy_choice" objects coming
> from advance_sj_state(). In greedy_search(), the call is under "if
> (has_sj)" so we don't see "semijoin_strategy_choice" if there is no
> semijoin. Could you please add the same if(has_sj) in
> optimize_straight_join()?
>
>> === modified file 'mysql-test/t/optimizer_trace_range.test'
>
>> +--echo
>> +# Make quick select for ordering inside test_if_skip_sort_order
>> +EXPLAIN SELECT * FROM t1 WHERE b BETWEEN 1 AND 2 ORDER BY b,a;
>> +--echo
>> +SELECT * FROM information_schema.OPTIMIZER_TRACE;
>
> In this trace, the mentioned quick select
> ("records_estimation_for_index_ordering") appears 3 times in
> join_optimization and once in join_execution. Do you have an idea why we
> call it so many times? That's just my curiosity.
> Update: I think you just sent a mail to the team about this.
>
>

-- 
Jørgen Løland | Senior Software Engineer | +47 73842138
Oracle MySQL
Trondheim, Norway