To improve a slow Snowflake query, open its profile in Snowsight, identify where execution work concentrates, and match the evidence to a targeted SQL, storage, or warehouse change. Then rerun the query under comparable conditions and compare both performance and cost. A profile shows where work occurs; it does not prove that a proposed change will help.
Open the query profile and establish where time went
- In Snowsight, go to Monitoring » Query History.
- Filter by the relevant user, warehouse, or time window, then select the query ID.
- Open the Query Profile tab. Your active role and privileges affect which history and profile details you can see.
Snowflake describes Query Profile as a way to examine “which parts of a query are taking the longest to execute.” Start with the Most Expensive Nodes pane, select a costly operator, and inspect its processing-time breakdown. Follow the data through the plan as well: look for large scans, row counts that grow unexpectedly after joins, and costly aggregations or sorts. You can also inspect operator statistics programmatically with GET_QUERY_OPERATOR_STATS.
Separate execution time from waiting
Elapsed time can include warehouse queueing as well as query execution. Check Query History and warehouse activity before attributing a slow wall-clock time to a SQL operator. For recurring workloads, Grouped Query History can help reveal changes in latency percentiles, failures, and frequency across parameterized query groups. Performance Explorer provides broader workload, warehouse, and table trends; visibility for these features also depends on privileges. See Snowflake’s Snowsight activity and Query History documentation.
For immediate post-run checks, Snowsight or Information Schema history functions may be more useful than delayed account usage views. Snowflake documents that ACCOUNT_USAGE QUERY_HISTORY can lag by up to 45 minutes and WAREHOUSE_LOAD_HISTORY by up to 3 hours. Check current documentation for latency and retention details before using these views in operational monitoring.
#1 Best Overall
Read scans, rows, and joins for signs of wasted work
Check whether a table scan prunes data
In each TableScan operator, compare partitions scanned with total partitions, and review bytes scanned and rows passed onward. If the query scans much of a table and a later filter discards most rows, investigate whether predicates are selective and whether the data is organized in a way that supports the workload’s common filters. Snowflake’s guidance on clustering, search optimization, and materialized views describes options that fit different access patterns. These are workload-specific choices and generally do not substantially improve queries that already run in one second or less.
Look for row growth and costly operators
Compare row counts before and after joins. An unexpected increase can point to a join condition that is missing or less restrictive than intended. Large aggregations, sorts, or deduplication steps may also dominate work; verify what result the SQL is meant to produce before changing them.
Rank #2
Use Query Insights as prompts, not automatic fixes
Query Insights describe detected conditions, their effects, and possible next steps. Documented insight types include joins without or with inefficient conditions, exploding joins, unnecessary aggregation, unnecessary UNION DISTINCT, remote spillage, and excessive warehouse queueing. Insights may also flag absent or ineffective filters, leading-wildcard LIKE patterns, or potential benefits from clustering, search optimization, or Snowflake Optima. See Snowflake Query Insights.
Before changing a join, removing DISTINCT, or replacing UNION DISTINCT, check whether the existing query intentionally returns duplicate rows or relies on its current join semantics. Make one change at a time and compare results as well as performance. Insights do not cover every query: Snowflake lists exclusions such as multi-step plans, secure objects, hybrid tables, Native Apps, EXPLAIN statements, reused results, and interactive tables. An empty insights pane does not establish that the query is healthy.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Choose a change that matches the bottleneck
| Profile evidence | What to investigate or test | Important check |
|---|---|---|
| Large scan or weak pruning | Review predicates, filter selectivity, and data organization. Consider clustering, search optimization, or a materialized view if it fits the access pattern. | Measure scan and row changes; storage features are not universal fixes. |
| Unexpected row growth after a join | Check join keys and conditions. Reduce rows before joining where the intended results allow it. | Confirm output semantics, including duplicate behavior. |
| Unneeded aggregation or deduplication | Review GROUP BY, DISTINCT, and UNION DISTINCT. | Remove only if doing so preserves the required result. |
| Local or remote spill | Find the spilling operator. Consider more warehouse memory/compute or processing the work in smaller batches. | Remote spill can sharply degrade performance; confirm whether spill falls after the change. |
| Warehouse queueing or concurrency pressure | Investigate warehouse load and concurrent work; address queueing or limit concurrency where appropriate. | A SQL rewrite may not resolve time spent waiting for warehouse resources. |
| Compute-bound, complex query | Test a larger warehouse and compare execution time. | Small, basic queries may not benefit; weigh latency against credits. |
| Eligible outlier workload | For ad hoc analytics, unpredictable query sizes, or large scans with selective filters, check Query Acceleration Service eligibility with SYSTEM$ESTIMATE_QUERY_ACCELERATION. | Snowflake documents QAS as an Enterprise Edition feature. Evaluate eligibility and service cost. |
| Repeated similar queries with low cache reads | Review warehouse cache use and suspension behavior; choose a cache policy that fits workload cadence and cost needs. | Suspending a warehouse drops its local cache. |
Warehouse size is not an automatic remedy: a larger warehouse can help larger, complex queries, but may not help small basic queries. For broader context on sizing, cache, concurrency, and cost, see Snowflake’s warehouse considerations and warehouse overview.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Rerun the query and validate the trade-off
- Save a baseline: record elapsed time and the profile evidence relevant to the suspected bottleneck, such as bytes and partitions scanned, rows, spill, and wait time.
- Change one likely cause, keeping the query’s intended output intact.
- Rerun under comparable conditions and compare duration and the same profile measures. For repeated workloads, compare distributions and trends rather than relying on a single run.
- Include warehouse credits or serverless-service cost when evaluating a resize or acceleration feature.
There is no universal speedup for a particular profile-driven change. Keep a change only when repeatable measurements show that it improves the workload without unacceptable cost or altered results.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
