> For the complete documentation index, see [llms.txt](https://docs.e6data.com/query-engine/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.e6data.com/query-engine/get-started/architecture/detailed-architecture-walkthrough/what-happens-when-you-run-a-query.md). # What happens when you run a query **ARCHITECTURE · QUERY LIFECYCLE** From SQL text to streamed results, every stage is handled by a dedicated component — and every stage is observable. *** ### 01 Connect & submit #### Protocol Layer *Connect & submit* A client submits SQL over the PostgreSQL wire protocol, the Trino protocol, the Spark protocol, or gRPC. The protocol layer authenticates the session and routes the statement to the planner for its workspace — no client rewrite required. ### 02 Transpile, parse & validate #### Transpiler · Query Planner *Transpile, parse & validate* SQL written in another engine's dialect is first transpiled to the E6 dialect. The planner then parses the query, resolves tables and columns against the metadata services, and validates types — surfacing errors in milliseconds, before any compute is spent. ### 03 Optimize #### Query Planner · Cost-based optimizer *Optimize* Rewrite rules, cost-based optimization, and a learning optimizer informed by past executions reorder joins, push down filters and projections, and exploit table-format metadata to prune partitions and files. The output is a physical plan sliced into distributable fragments. ### 04 Schedule #### Distribution Services *Schedule* Admission control places the query, allocates executors, and enforces workload isolation — so a heavy ad-hoc query and a latency-sensitive dashboard can share the same cluster predictably. ### 05 Execute #### Distributed Executors · Native Engine *Execute* Plan fragments run in parallel across the executor fleet as pipelines of vectorized columnar operators, exchanging data between executors for large joins and aggregations. Kernels run in native Rust on Apache Arrow; scans hit the multi-tier cache first, then read open table formats from your lake in place, with spill-to-disk as a fallback for workloads that exceed memory. ### 06 Stream results #### Protocol Layer → Client *Stream results* Results stream back to the client as they are produced, in columnar form end to end. Execution metrics — per-operator timings, rows read, cache hits, spill volume — are captured in query history for every statement. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.e6data.com/query-engine/get-started/architecture/detailed-architecture-walkthrough/what-happens-when-you-run-a-query.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.