optimizing-query-by-id

Analyze Snowflake query_id metrics and rewrite SQL for improved performance.

2|Updated Apr 8, 2026
One-click install
npx skills add https://github.com/miptah21/skills --skill optimizing-query-by-id
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: optimizing-query-by-id
Source: https://github.com/miptah21/skills/tree/main/.agents/skills/optimizing-query-by-id
Command: npx skills add https://github.com/miptah21/skills --skill optimizing-query-by-id

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It eliminates slow, resource-heavy Snowflake queries by turning a query_id into actionable performance diagnostics and an optimized rewritten SQL.

Core Features & Use Cases

  • Fetch & analyze query performance from query_id: Retrieves query text and key metrics like execution time, bytes scanned, spillage, and partition pruning.
  • Inspect operator-level bottlenecks: Uses query operator statistics to spot row explosions, heavy scans, and spillage-causing operators.
  • Rewrite and verify improvements: Produces an optimized query, validates via EXPLAIN, and summarizes expected gains against performance thresholds.

Use Case: You have a previously executed Snowflake query that is slow; provide its query_id and receive an optimized SQL rewrite with before/after plan comparison guidance.

Quick Start

Provide the Snowflake query_id to analyze and rewrite, then ask the assistant to return the optimized SQL plus a concise summary of expected performance improvements.

Frequently Asked Questions about optimizing-query-by-id

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I optimize a slow Snowflake query using a query ID?

Snowflake query optimization using a query ID retrieves execution metrics like bytes scanned and spillage, inspects operator statistics for bottlenecks, and produces a rewritten SQL validated via EXPLAIN.

Why does my Snowflake query have high spillage and how can I fix it?

High spillage in Snowflake queries occurs when operators exceed memory limits. Profiling via GET_QUERY_OPERATOR_STATS identifies spillage-causing operators, allowing targeted SQL rewrites to reduce data volume and improve execution.

What is the best way to check if partition pruning is working in Snowflake?

Checking partition pruning effectiveness in Snowflake requires analyzing query history and operator statistics. Profiling the query ID reveals bytes scanned and partition pruning metrics to determine if pruning is applied successfully.

Can I diagnose Snowflake query bottlenecks from query history alone?

Diagnosing Snowflake query bottlenecks from query history provides initial metrics like execution time and bytes scanned. Inspecting operator-level statistics via GET_QUERY_OPERATOR_STATS is required to pinpoint row explosions and heavy scans.

How do I validate SQL rewrite improvements in Snowflake before executing?

Validate SQL rewrite improvements in Snowflake by running EXPLAIN on the rewritten query. This provides a structured before/after plan comparison against performance thresholds to confirm expected gains without full execution.

When should I rewrite SQL instead of scaling up the Snowflake warehouse?

Rewrite SQL instead of scaling up the Snowflake warehouse when profiling indicates inefficient partition pruning, row explosions, or heavy scans. Optimizing the query structure reduces bytes scanned and spillage without increasing compute costs.