Runtime query codegen — the JIT path.

Two shapes compile today:

• single-table scan / filter / project / sort, and
• two-table LEFT JOIN on an equi-key — hash-joined, with NULL-filled non-matches, residual ON filters pushed into the index build, and 2-arg COALESCE(col, literal) projections.

For either, this compiles a parsed %ExSQL.AST.Select{} into a native BEAM function (via Module.create/3, which the compiler/JIT turns into machine code) rather than walking the AST per row. Columns are read positionally from the stored row tuple (:erlang.element/2), and SQL semantics are preserved by delegating comparisons/booleans/affinity to ExSQL.Value — the exact functions the tree walker uses.

Literals are lifted to a params tuple so a query shape compiles once and is reused for any literal values (WHERE x > 30 and WHERE x > 40 share a module; the value is a runtime argument). Compilation costs a few ms and only pays off for repeated/prepared queries, so the caller gates on that and falls back to the tree walker for anything compilable?/2 rejects.

The generated function takes the table's positional rows ([{rowid, tuple}], scan order) plus a params tuple and returns [[value, ...]] — the same shape as a tree-walked result's rows. The scan form is run(rows, params); the join form is run(left_rows, right_rows, params), which indexes the right side by the (affinity-canonicalized) join key and probes it once per left row, then re-verifies each candidate with an exact comparison before emitting.