Execution Plan Analysis

PawSQL Execution Plan Analysis transforms native database execution plans into more intuitive graphical structures so developers and DBAs can understand SQL execution paths faster. It is designed not only to show which operators exist, but also to help identify performance bottlenecks, explain optimization results, and compare execution plans before and after tuning.

This page focuses on rendering plans and locating bottlenecks. For before-and-after cost validation and judgment, see Performance Validation.

Overview

Database execution plans may contain many layers of operators, cost estimates, row estimates, and database-specific attributes. For complex SQL, reading raw text plans can be difficult and time-consuming. PawSQL converts execution plans into a normalized visual structure:

Why Execution Plan Analysis Matters

SQL performance optimization ultimately requires understanding how the database intends to execute the SQL. SQL text alone cannot answer many important questions:

Is the database using an index?
Which table is being fully scanned?
Is the join using Hash Join or Nested Loop?
Which operator has the highest cost?
Is Sort or Aggregate becoming a bottleneck?
Are estimated rows expanding dramatically?
Is a distributed database redistributing data across nodes?

Execution plans provide this information, and visualization makes complex plans easier to interpret.

Key Capabilities

Plan tree visualization

Display execution-plan operators and parent-child relationships as a tree or graph. Typical operators include:

Table Scan
Index Scan
Index Seek
Nested Loop
Hash Join
Merge Join
Sort
Aggregate
Materialize
Exchange / Redistribute

Cost visibility

Show key metrics at plan nodes, such as:

Node Cost
Total Cost
Estimated Rows
Actual Rows, when available
Width / Data Volume
Execution Time, when present in the plan

Bottleneck identification

Help identify:

High-cost operators
Full table scans
Large sorts
Row-count explosion
Large-table Nested Loops
Join skew
Distributed data movement

Before-and-after comparison

When used with Performance Validation, PawSQL can compare:

Original execution plans
Plans after SQL rewrite
Plans after index recommendation

This makes access-path changes visible rather than implicit.

Example

Suppose the original plan is:

Nested Loop
├── Seq Scan orders
└── Index Scan customers

After optimization:

Hash Join
├── Index Scan orders
└── Index Scan customers

Visualization should help the user understand not only that operators changed, but also:

Why the access path changed
Which node became cheaper
Whether scanned data volume decreased
Whether the new index is actually being used