List:Commits« Previous MessageNext Message »
From:Jorgen Loland Date:October 21 2010 1:00pm
Subject:Re: one trace per row scanned, by range optimizer
View as plain text  
Hello Guilhem,

>> To reduce it even further, maybe we could disable tracing in
>> subselect_*_engine::exec, but I haven't investigated if that makes
>> sense yet. There may be other information we need from the
>> subselect*::exec() functions, and especially the first time exec() is
>> called. Maybe tracing can be disabled only on second execution and
>> onwards?
> I'm thinking about this:
> have a counter in JOIN (or in select_lex), counting the number of times
> this JOIN's exec() has been called; when the number exceeds a maximum
> (1?), we don't trace this JOIN's exec() anymore. The idea being that the
> first call brings useful info, but the subsequent calls don't. Then we
> probably need an option to set this counter (for the case where a bug
> happens in the 36th exec() of a JOIN and we want to trace this)?

I don't think we need a counter. All we need is to check the join->optimized 
variable since it's false only when exec() is called for the first time. (I 
think - didn't really check that this is correct)

>> So my reply is:
>> I think it should be possible to print this range information by
>> enabling an optimizer feature. My suggestions:
>> 1) We can be satisfied with disabling tracing below
>> join_init_quick...() and accept 14 lines of output per record, or
> sounds too much to me
>> 2) We can disable tracing earlier, e.g. in subselect*::exec() the second
>> time it is called and onwards. We could e.g. cut down to 3 lines
>> (below) or hide exec completely by not tracing anything.
>> {
>> "subselect_single_select_exec_steps": "..."
> even an ellipsis repeated for each record could lead to a big trace. I
> would go silent after the first record.

Agreed. Follow-up question: go silent after the first record only if 
DYNAMIC_RANGE disabled or should I just remove this flag (from my sandbox)?

Jørgen Løland | Senior Software Engineer | +47 73842138
Oracle MySQL
Trondheim, Norway
one trace per row scanned, by range optimizerGuilhem Bichot15 Oct
  • Re: one trace per row scanned, by range optimizerGuilhem Bichot16 Oct
    • Re: one trace per row scanned, by range optimizerJorgen Loland18 Oct
      • Re: one trace per row scanned, by range optimizerGuilhem Bichot21 Oct
        • Re: one trace per row scanned, by range optimizerJorgen Loland21 Oct
          • Re: one trace per row scanned, by range optimizerGuilhem Bichot22 Oct