Optimizer Trace for Developers

You are viewing an old version of this article. View the current version here.

This article describes guidelines for what/how to write to Optimizer Trace when doing server development.

Basic considerations

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_object and 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.

Test coverage

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 Attachment 'mtr_opttrace' not found pass in kvm-fulltest and kvm-fulltest2.


In newer MariaDB versions, there is <<code>> const char *dbug_print_opt_trace(); <<code>> function which one can use to print the trace produced so far.


Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.