> 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/guides/querying/query-performance-basics.md).

# Query performance basics

Practical levers for faster, cheaper queries in e6data - sizing, caching, execution mode, the transpiler, and reading execution details.

A handful of levers cover most query-performance work in e6data. This page is a practical starting point; for the underlying mechanics, see [How e6data works](/query-engine/get-started/readme/how-e6data-works.md).

## Start with the query

* **Filter early and prune partitions.** Predicates on partition columns let the engine skip data it never reads. Queries that scan whole fact tables without filters are the most common cause of slowness.
* **Select only the columns you need.** Wide `SELECT *` over columnar data reads more than necessary.
* **Set a row limit while exploring.** Use a `LIMIT` to preview results without running unbounded scans - see [Run queries and view results](/query-engine/guides/querying/run-queries-and-view-results.md).

## Read the execution details

After a run, open the query's execution details to see the **Total Elapsed Time** broken into planning, queueing, and execution, plus the **Query Profile** showing the most expensive steps. This tells you whether time is going to queueing (cluster under-provisioned), planning, or execution (the query itself). See [Run queries and view results](/query-engine/guides/querying/run-queries-and-view-results.md#execution-details).

## Cluster-side levers

| Lever                      | When it helps                                                                 | Where                                                                                                                                |
| -------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Right-size the cluster** | Queries queue or run slowly under concurrency                                 | [Cluster sizing and scaling](/query-engine/guides/clusters/cluster-sizing-and-scaling.md)                                            |
| **Autoscaling**            | Variable or spiky load                                                        | [Cluster sizing and scaling](/query-engine/guides/clusters/cluster-sizing-and-scaling.md)                                            |
| **Result caching**         | The same queries run repeatedly against unchanged data                        | [Cluster sizing and scaling](/query-engine/guides/clusters/cluster-sizing-and-scaling.md#result-caching)                             |
| **Native execution mode**  | Scan-heavy queries with simple filters, joins, and aggregations               | [Cluster sizing and scaling](/query-engine/guides/clusters/cluster-sizing-and-scaling.md#execution-modes)                            |
| **SQL transpiler**         | You're running SQL written for another dialect (Snowflake, Trino, Databricks) | Cluster settings - see [Create and manage clusters](/query-engine/guides/clusters/create-and-manage-clusters.md#configure-a-cluster) |

## A simple workflow

1. Run the query and open its execution details.
2. If queueing dominates, scale the cluster up or enable autoscaling.
3. If execution dominates, look at the Query Profile - add filters, prune partitions, or try native execution for scan-heavy patterns.
4. For repeated reports, enable result caching.
5. Measure again.

## See also

* [Run queries and view results](/query-engine/guides/querying/run-queries-and-view-results.md)
* [Cluster sizing and scaling](/query-engine/guides/clusters/cluster-sizing-and-scaling.md)


---

# 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/guides/querying/query-performance-basics.md?ask=<question>&goal=<endgoal>
```

`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.