Ask why a query is slow before you rewrite it.

Before you start

A query that's actually slow, ideally with a known runtime to compare against, and your own API key added under Settings → AI Assistant.

Steps

1. Run the slow query and note its runtime, or open its recent query history.
2. Click Ask (⌘L) and attach Current query, plus Last error if it timed out.
3. Ask something like: "Why is this query slow, and what's one change to try?"
4. Read the answer and the SQL it proposes; use Insert into editor to try it, or Run.
5. Compare runtime before and after; Watch this on the runtime if it's a recurring job.

A worked example: a bad join order on Snowflake

SELECT e.event_id, u.email, e.event_type, e.created_at
FROM analytics.raw_events e
JOIN analytics.large_user_dim u ON e.user_id = u.user_id
WHERE e.created_at >= DATEADD(day, -7, CURRENT_DATE())
  AND u.region = 'EU';

Attached as Current query, a likely answer flags the join order: large_user_dim gets joined in full before the region = 'EU' filter narrows it down, so the join is working against every row in a large dimension table when filtering it first would shrink what has to be joined at all. A proposed rewrite pushes that filter into a CTE first:

WITH eu_users AS (
  SELECT user_id, email FROM analytics.large_user_dim WHERE region = 'EU'
)
SELECT e.event_id, u.email, e.event_type, e.created_at
FROM analytics.raw_events e
JOIN eu_users u ON e.user_id = u.user_id
WHERE e.created_at >= DATEADD(day, -7, CURRENT_DATE());

Use Insert into editor to drop that version in as a second query tab, run both, and compare. Snowflake's optimizer sometimes reorders joins on its own, so the gain isn't guaranteed, but filtering the smaller side first before a join is a pattern worth testing whenever one side of a join is much larger than the other.

Giving it the execution plan for a better answer

Ask reasons from the SQL and your schema unless you hand it more. Run EXPLAIN or pull the query profile from Snowflake's history and paste the output alongside your question, "here's the query and its profile, what's the actual bottleneck," and the answer moves from a plausible hypothesis about the SQL's shape to something grounded in what actually happened when it ran, spill to local storage, a partition scan, a specific operator with an outsized row count.

What this doesn't do

Ask proposes a change, it doesn't auto-tune your warehouse, add an index, or re-run your job with the new SQL in place of the old one. It also isn't reading Snowflake's actual query profile unless you paste that output into the conversation, without it, the suggestion comes from the SQL's shape and your schema, not measured execution statistics. Treat the answer as a second pair of eyes worth testing, not a guaranteed fix.

A smaller, more common case

Not every slow query is a join order problem. A simpler and more frequent culprit:

SELECT * FROM analytics.raw_events
WHERE CAST(created_at AS DATE) = '2026-09-01';

Wrapping created_at in CAST defeats an index or partition pruning on that column, since the warehouse can no longer tell in advance which range of the underlying data the filter applies to. Ask would likely flag the cast itself and suggest a range comparison instead: created_at >= '2026-09-01' AND created_at < '2026-09-02', which keeps the column bare so pruning can still apply.

Check it worked

Compare the runtime of the original and the rewritten query on the same warehouse size and roughly the same data volume. If the rewrite doesn't move the runtime, the bottleneck is probably elsewhere, warehouse size, concurrent load, or a scan that neither version avoids.

Treat every suggestion as a hypothesis

The point of asking first is to have a specific theory to test, join order, a wrapped column, a missing filter, rather than rewriting a slow query by trial and error. Some suggestions won't move the needle, and that's still useful information: it tells you the bottleneck is somewhere Ask can't see from the SQL alone, and narrows where to look next.

Troubleshooting