Optimizer Trace for Developers
This article describes guidelines for what/how to write to Optimizer Trace when doing server development.
The trace is a "structured log" of what was done by the optimizer. Prefer to do tracing as soon as a rewrite/decision is made (instead of having a separate trace_something() function).
(TODO other considerations)
Making sure the trace is valid
Json_writer_array classes use RAII idiom and ensure that JSON objects and arrays are "closed" in the reverse order they were started.
However, they do not ensure these constraints:
- JSON objects must have named members.
- JSON arrays must have unnamed members.
Tracing code has runtime checks for these. Attempt to write invalid JSON will cause assertion failure.
It is possible to run
mysql-test-run with this argument
This will run all tests with tracing on. As mentioned earlier, debug build will perform checks that we are not producing invalid trace.
The BuildBot instance at http://buildbot.askmonty.org/ also runs tests with this argument, see
mtr_opttrace pass in kvm-fulltest and kvm-fulltest2.
In newer MariaDB versions, there is
const char *dbug_print_opt_trace();
function which one can use to print the trace produced so far.