Explain the internal working of the Spanner query execution engine?

Once the optimizer picks a plan, Spanner executes it as a tree of operators, distributed across whichever splits the query touches, and streams partial results back rather than materializing the whole result set at once.

For a query that only touches one split, execution is straightforward: the leader replica for that split runs the plan locally. For a query spanning multiple splits, for example a range scan across a large interleaved table, Spanner distributes the relevant operator subtrees to each split involved, and a coordinating node merges and, if needed, re-sorts or re-aggregates the partial results (for operations like ORDER BY, GROUP BY, or joins that cross split boundaries). Interleaved tables let some joins execute entirely within a split, avoiding this fan-out and merge step, which is a major reason interleaving is recommended for hot, frequently-joined parent-child access patterns rather than left as separate, non-interleaved tables.