Hello,
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
problems:
- 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.
