List:Commits« Previous MessageNext Message »
From:Guilhem Bichot Date:October 22 2010 12:16pm
Subject:Re: one trace per row scanned, by range optimizer
View as plain text  

Jorgen Loland a écrit, Le 21.10.2010 15:00:
> Hello Guilhem,
> (cut)
>>> 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)

depends on what exec() you're talking about.
I think you mean subselect_blah::exec(), then you must be right.
I was talking about JOIN::exec(): when we reach JOIN::exec(), 
JOIN::optimized is true for sure.
>>> 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": "..."
> (cut)
>> 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)?

I don't know. I would need to experiment a bit. There seems to be 2 
- dynamic range producing trace for each record, without any subquery
- subquery producing trace for each outer record
So I don't know what stone kills those two birds.

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