Mini DBA PostgreSQL execution plan controls help you inspect EXPLAIN output for selected activity and query rows. PostgreSQL plan review is most useful after you identify a costly statement from Activity, Queries, Waits, I/O, or Indexes and need to understand whether the SQL is scanning too much data, joining inefficiently, sorting heavily, or missing a better access path.
Where To Open PostgreSQL Plans
PostgreSQL execution plan detail can be opened from:
- PostgreSQL Activity for selected live sessions where plan text or XML is available.
- PostgreSQL Queries for selected query rows where Mini DBA can load plan detail.
The plan detail appears in the SQL detail modal beside the SQL Statement and Details tabs. The Execution Plan tab can show a plan count, loading state, refresh or load controls, and options to open the plan diagram or HTML in a new browser tab.
Plan availability depends on PostgreSQL version, extensions, permissions, query text, database context, and whether Mini DBA can safely request plan data. If plan detail is unavailable, continue with query statistics, waits, indexes, and logs.
PostgreSQL Plan Detail Controls
The PostgreSQL SQL detail modal starts with the SQL statement and related fields, then provides an Execution Plan tab. Depending on the source and available data, the plan tab can include:
- Plan text from PostgreSQL EXPLAIN output.
- Plan XML where available.
- An embedded visual plan diagram.
- A load or refresh control when the plan must be fetched for the selected query.
- Open In New Tab for the PostgreSQL plan visualizer.
- Open HTML for a standalone text and XML review page.
- An AI Assistant tab that passes the SQL text and plan context.
The visualizer is useful for navigating plan shape. Use it to identify expensive branches, joins, scans, sorts, aggregates, and row-flow patterns. When the visual view points to a suspicious area, compare it with the raw plan text so you can record the exact node, relation, cost, and estimated row evidence.
How To Read PostgreSQL Plans In Mini DBA
Start by asking what problem the plan should explain. A high-duration query might be expensive because it scans too much data, waits on locks, performs repeated nested loops, sorts large result sets, reads from disk, or returns far more rows than the application needs.
Review these areas:
- Sequential scans on large tables when a selective predicate should use an index.
- Nested loops that multiply row counts unexpectedly.
- Hash joins or merge joins that may be reasonable for large sets but expensive for the current workload.
- Sorts and aggregates that process many rows or spill outside memory.
- Estimated rows that are far away from expected reality.
- Filter predicates that remove many rows after an expensive scan.
- Missing or stale statistics that could lead to poor plan choices.
Mini DBA does not make schema changes from the plan viewer. Use the plan to decide what evidence to collect next: table size, index definitions, pg_stat_statements history, wait events, autovacuum behavior, and application calling patterns.
Drill Down From Query To Plan
For live incidents, begin on PostgreSQL Activity. Select the active or waiting session, review the SQL statement and details, then open the Execution Plan tab if a plan is available. This helps connect the currently affected user or application process to the plan evidence.
For recurring workload, begin on PostgreSQL Queries. Sort by total time, mean time, execution count, reads, or another available cost measure. Open the query detail, load the execution plan, then compare with PostgreSQL Waits and PostgreSQL Indexes.
When drilling into expensive plan nodes, keep a note of the table, predicate, join, row estimate, and plan source. This prevents vague tuning requests such as "add an index" and turns them into testable recommendations such as "verify whether this predicate needs an index and whether the table's write workload can tolerate it."
Ask AI About A PostgreSQL Plan
The PostgreSQL plan controls include an AI Assistant tab where plan context is available. Mini DBA passes the SQL text, plan text, plan XML where available, and source context. This is more useful than asking a generic AI question because the assistant receives the exact plan evidence from the selected query.
Useful prompts include:
Explain the plan nodes most likely to affect runtime and list what I should verify in PostgreSQL.Does this plan suggest a missing index, stale statistics, poor join order, or a query rewrite?Which checks should I run before creating an index for this query?Always validate AI recommendations against write overhead, table growth, autovacuum, and application behavior.
Related Pages
- Execution Plan Analysis
- PostgreSQL Activity
- PostgreSQL Queries
- PostgreSQL Waits
- PostgreSQL Indexes
- PostgreSQL Performance Tuning