What problem does it solve?
Console and catalog queries that read Materialize system relations (mz_catalog / mz_internal) can be slow, but it is hard to know whether a rewrite actually helps without a faithful way to measure it. This Skill provides a repeatable two-phase method: diagnose the query plan on the real relations, then measure candidate rewrites with a synthetic-fleet latency sweep.
Core Features & Use Cases
- Plan diagnosis with EXPLAIN: Run the query on mz_catalog_server and detect known anti-patterns such as filters applied after Top-1/Reduce, full scans of history relations, redundant self-joins, missing temporal filters, and fleet-wide aggregations for single-entity views.
- Faithful synthetic benchmarking: Build shadow tables that replicate production indexes, generate a synthetic fleet at realistic scale, and compare old vs. rewritten queries with concurrent peek drivers measuring p50/p95 and qps.
- Validation guardrails: Verify output equivalence between variants, confirm plan differences reproduce on the bench cluster, and avoid pitfalls like unindexed shadows or cross-run compaction noise.
- Use Case: A Console cluster-utilization query scans all replicas before filtering to one. Use this Skill to EXPLAIN the plan, push the filter to the source read, and prove the latency win with a 200-cluster synthetic sweep.
Quick Start
Analyze this Console SQL query that reads mz_catalog relations, diagnose its plan on mz_catalog_server, and benchmark my proposed rewrite with a synthetic fleet sweep.
