YugabyteDB YSQL Query Analysis

This skill diagnoses performance at the SQL and session layer — from identifying slow queries and wait events to tuning plans and running structured database assessments. It works across all deployment types and at any level of access.

Output discipline — advisory only; no changes without explicit approval

This skill is diagnostic and read-only by default. Only read-only investigation runs without asking — the triage snapshot, pg_stat_statements/pg_stat_activity/pg_locks/ASH queries, EXPLAIN, and catalog reads. EXPLAIN ANALYZE executes the statement: before using it, ask the user whether the target is production (a host or cluster name is a hint, not confirmation). Non-production: run it freely, but still wrap INSERT/UPDATE/DELETE in BEGIN; … ROLLBACK; so test data isn't changed. Production: only reads, or writes inside BEGIN; … ROLLBACK;, and ask first if in doubt. The default deliverable is succinct guidance: findings and recommended fixes for the user to review — not changes you apply.

Never run a statement that mutates state or disrupts the running system without the user's explicit approval — including DDL (CREATE INDEX, DROP, ALTER, ALTER DATABASE/ALTER SEQUENCE … SET), session/transaction termination (pg_terminate_backend, yb_cancel_transaction), statistics resets (pg_stat_statements_reset, yb_pg_stat_plans_reset), session/database SET of GUCs (one exception: SET statement_timeout = '30s' in your own diagnostic session is allowed without asking — run it before diagnostic queries so none runs unbounded; it changes no data), GFlag or runtime-config changes, or restarts. This includes "diagnostic" mutations such as enabling a flag via ALTER DATABASE … SET or resetting stats: propose them and let the user run them (a session-scoped SET the user is asked to run in their own session is fine to recommend). Present the exact command and its effect; the user runs it or explicitly approves you running it.

START HERE — run the triage snapshot first (when you have live access)

Whenever you have live SQL access and the task is "why is this slow" / "assess this database" / "something is performing poorly", your first action is to run the one-shot triage script, before you write any EXPLAIN or invent your own diagnostic queries:

ysqlsh -h <host> -p 5433 -d <database> -f references/triage-snapshot.sql

On a YBA-managed Kubernetes universe there is no plain host:port — YSQL runs inside the tserver pods. Connect via kubectl exec or a port-forward first; see references/access-yba-k8s.md. (For a whole-universe "assess for any performance issues" request that should also cover infrastructure/metrics, start from the yb-performance-assessment orchestrator, which runs this SQL triage and the metrics health check.)