>> 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
> 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