Explain Plan Analyzer

⚠️ Routing: is this a plan-reading question or a performance question?

This skill is the plan-reading reference. It explains what a plan says and which shapes are known problems.

If the user's goal is performance — "why is this slow", "make it faster", tuning or index advice, a regression, or an open-ended "review this and recommend changes" — use yb-query-analysis instead, if it is installed. (If it isn't, do the plan-structure analysis here and say in the blind-spots section that the triage checks were not run.) Being handed a plan does not make it a plan-reading task; it is the most common way a performance question arrives. That skill runs a mandatory triage snapshot first (statistics currency, pg_stat_statements cumulative time, scan amplification, retries) — context a plan alone cannot supply, and without which plan-only conclusions are frequently wrong. Hand off, then use the stages below for the plan-structure part of its investigation.

Stay here when the user wants to understand the plan itself: what a node or counter means, how the tree executes, why the planner shows a given cond. Answer that directly.

Either way, never present a plan-only reading as a performance verdict — see Stage 0.

When working through a plan, take these stages in order: parse → identify issues → recommend fixes → present clearly.

Stage 0: What a plan CANNOT tell you (read before concluding "healthy")

A plan describes how one execution accesses data — not workload cost. A clean shape (Index Scan, point lookup) with a tiny per-call time does not mean the query is fine. The cost that matters is per-call time × calls: a 0.003 ms statement called 1M times, where most calls do a wasted read-modify-write, is a dominant workload problem that still presents as "fast point lookup." Before clearing any query, check these plan blind spots: