List:Commits« Previous MessageNext Message »
From:Jorgen Loland Date:November 10 2010 7:35am
Subject:Re: bzr push into mysql-next-mr-bugfixing branch (guilhem:3228 to
3229)
View as plain text  
On 11/05/2010 11:20 AM, Guilhem Bichot wrote:
> Hello Jorgen,
>
> Jorgen Loland a écrit, Le 26.10.2010 13:42:
>> > === modified file 'mysql-test/r/mysqld--help-win.result'
>> > --- mysql-test/r/mysqld--help-win.result 2010-09-24 07:19:35 +0000
>> > +++ mysql-test/r/mysqld--help-win.result 2010-10-26 06:18:20 +0000
>> > @@ -409,6 +409,24 @@ The following options may be given as th
> > + --opt>> > loosescan, firstmatch, mrr, mrr_cost_based,
>> > index_condition_pushdown} and val is one of {on, off,
>> > default}
>imizer-trace=name
>> > + Controls tracing of the Optimizer:
>> > + optimizer_trace=option=val[,option=val...], where option
>> > + is one of {enabled, end_marker, one_line} and val is one
>> > + of {on, off, default}
>> > + --optimizer-trace-features=name
>> > + Enables/disables tracing of selected features of the
>> > + Optimizer:
>> > + optimizer_trace_features=option=val[,option=val...],
>> > + where option is one of {misc, greedy_search} and val is
>> > + one of {on, off, default}
>> > + --optimizer-trace-limit=#
>> > + Maximum number of shown optimizer traces
>>
>> I think it would be clearer if you change "shown" to "stored".
>
> Here we need to think about this.
> "shown" is the most exact word. Consider this case:
> optimizer_trace_offset=-5
> optimizer_trace_limit=1
> I start a session, I execute statement#1, #2, #3, #4, #5.
> I read OPTIMIZER_TRACE I find only one trace, the trace of #1.
> If we "store" only optimizer_trace_limit (1 here) traces, #1 is all we
> have in memory.
> Then I issue a new statement #6, which creates a new trace;
> OPTIMIZER_TRACE should now show me the trace of #2, but it cannot,
> because it doesn't have it in memory (we stored only one trace: #1).
> In fact, we had to store #1,#2,#3,#4,#5 (always the last 5 ones i.e. the
> value of "optimizer_trace_offset"), and show only 1 (the value of
> "optimizer_trace_limit").
> That's why I used "shown" instead of "stored".
>
> If optimizer_trace_offset>=0, we do an optimization of the logic above,
> storing only optimizer_trace_limit traces indeed.
>
> Ideas?

In that case, shown is OK (and this is not important anyway :)

-- 
Jørgen Løland | Senior Software Engineer | +47 73842138
Oracle MySQL
Trondheim, Norway
Thread
bzr push into mysql-next-mr-bugfixing branch (guilhem:3228 to 3229) Guilhem Bichot22 Oct
Re: bzr push into mysql-next-mr-bugfixing branch (guilhem:3228 to3229)Jorgen Loland26 Oct
  • Re: bzr push into mysql-next-mr-bugfixing branch (guilhem:3228 to3229)Guilhem Bichot5 Nov
    • Re: bzr push into mysql-next-mr-bugfixing branch (guilhem:3228 to3229)Jorgen Loland10 Nov
  • Re: bzr push into mysql-next-mr-bugfixing branch (guilhem:3228 to3229)Jorgen Loland9 Nov
    • Re: bzr push into mysql-next-mr-bugfixing branch (guilhem:3228 to3229)Guilhem Bichot12 Nov
      • Re: bzr push into mysql-next-mr-bugfixing branch (guilhem:3228 to3229)Jorgen Loland15 Nov
        • Re: bzr push into mysql-next-mr-bugfixing branch (guilhem:3228 to3229)Guilhem Bichot15 Nov
    • Re: bzr push into mysql-next-mr-bugfixing branch (guilhem:3228 to3229)Guilhem Bichot15 Nov