You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By me:
WL#5257 Create a first API for the Optimizer trace
By Jorgen Loland:
WL#5594 Add optimizer traces to the range optimizer
WL#5741 Ensure optimizer tracing for subqueries works without JSON syntax errors
WL#5581 Add --opt-trace-protocol to MTR.
Summary below.
* This feature produces a trace for any SELECT/INSERT/UPDATE/DELETE/DO/SET/CALL,
which contains information about decisions taken by the optimizer during
the optimization phase (choice of table access method, various costs,
transformations, etc). It should help understand the logic followed by the
optimizer for a particular query. Trace is session-local, controlled by the
@@optimizer_trace variable and other new variables, and readable by selecting
from information_schema.optimizer_trace. See the doxygen comments in opt_trace.h
for more info.
* By default the tracing code is compiled in, but not enabled
at runtime; set @@optimizer_trace to enable it.
* Changes to test results: unless otherwise noted they are due to those changes:
** The query printed by EXPLAIN EXTENDED now shows the id of each SELECT,
to help interpret the "id" column.
** EXPLAIN EXTENDED now prints triggered conditions as:
trigcond_if(outer_field_is_not_null, <is_not_null_test>(`test`.`t2`.`s1`), true)
instead of:
trigcond(<is_not_null_test>(`test`.`t2`.`s1`).
* @@optimizer_trace_offset is a signed variable, so I had to add support for
this in MySQL (so far all integer system variables were unsigned, it was impossible
to set a system variable to a negative value, it would be rounded to 0).
0 commit comments