bigquery-sql

Optimizes BigQuery SQL queries using column pruning, predicate pushdown, and join strategies.

Updated Jul 7, 2026
One-click install
npx skills add https://github.com/ricardolui/gcp-custom-agent-skills --skill bigquery-sql-ricardolui
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: bigquery-sql
Source: https://github.com/ricardolui/gcp-custom-agent-skills/tree/main/bigquery-sql
Command: npx skills add https://github.com/ricardolui/gcp-custom-agent-skills --skill bigquery-sql-ricardolui

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing BigQuery SQL that is slow or expensive is a common pain point for data teams. This Skill applies proven optimization rules to reduce query costs, improve execution speed, and enforce performance best practices automatically. ## Core Features & Use Cases - Automatic Optimizations: Applies column pruning, common subexpression reuse, predicate pushdown, and early aggregation to every query. - Mandatory Rewrites: Converts inefficient patterns like WHERE col IN (SELECT ...) and WHERE (SELECT COUNT(*)) > 0 into efficient EXISTS clauses. - Conditional Improvements: Proposes UNION ALL and APPROX_COUNT_DISTINCT rewrites with confirmation when approximate results are acceptable. - Use Case: A data engineer has a slow dashboard query scanning terabytes. Use this Skill to rewrite the query with predicate pushdown and early aggregation, cutting scan volume and slot time. ## Quick Start Optimize this BigQuery SQL query for performance and cost, and summarize the optimizations applied.

Frequently Asked Questions about bigquery-sql

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

FAQPage Schema
How do I optimize a slow BigQuery SQL query?

Apply column pruning to remove unused columns, push WHERE filters as early as possible, and perform GROUP BY before joins. Also rewrite IN subqueries as EXISTS clauses and choose TABLE materialization for expensive intermediate results.

How to reduce BigQuery query costs?

Reduce costs by pruning unnecessary columns and applying predicate pushdown to limit scanned data early. Materializing expensive intermediate nodes as TABLEs avoids recomputation, and APPROX_COUNT_DISTINCT lowers memory usage for cardinality estimates.

When should I use a VIEW versus a TABLE in BigQuery?

Use a VIEW for small datasets or simple transformations where recomputation is cheap. Use a TABLE for large datasets, expensive computations, or intermediate nodes referenced multiple times in downstream queries.

Why replace IN subqueries with EXISTS in BigQuery?

EXISTS clauses with SELECT 1 are more efficient than WHERE col IN (SELECT ...) because they stop scanning once a match is found. The same rewrite applies to COUNT(*) > 0 checks, which should become EXISTS predicates.

What are the tradeoffs of APPROX_COUNT_DISTINCT in BigQuery?

APPROX_COUNT_DISTINCT is faster and uses less memory than COUNT(DISTINCT), but returns an approximate rather than exact count. It should only be applied with confirmation when approximate cardinality is acceptable for the analysis.