#storage-engine
Posts
-
Digging into MariaDB's Source 2: The Big Picture — the Server Layer, Storage Engines, and the Life of One Query
The map for this series, written for intermediate developers opening the MariaDB source for the first time. Why the server layer (sql/) and the storage engines (storage/) are separate, what their boundary looks like — handler (one opened table) and handlerton (one table of function pointers per engine) — the path one SELECT takes from connection → THD → parsing → preparation → optimization → execution → handler → engine and back through Protocol, and MEM_ROOT, which throws all those objects away in one go after every statement. Checked against the real source and gdb backtraces.
-
Digging into MariaDB's Source 9: Execution and the Handler API — How the Nested-Loop Join Calls the Engine
We follow, in the source, the place where the optimizer's plan actually reads rows. From JOIN::exec() into the nested loop of do_select(), sub_select() and evaluate_join_record(), through the read functions chosen for each EXPLAIN type and the join buffer, past the handler's ha_ wrappers, and down to ha_innobase::rnd_next() and write_row(). We count calls with the Handler_read_* status variables, confirm the whole path from do_command to the engine with one gdb backtrace, and see that switching the engine to MEMORY, Aria or BLACKHOLE still goes through the same spots.