Cost Breakdown

Standard PostgreSQL EXPLAIN gives each node a single Total Cost number — a unitless estimate of how expensive that step is. The cost breakdown, marked with an asterisk (*) in IndeX-Ray, splits that number into its component parts so you can see why a node is expensive, not just that it is.

This is augmented by the analyzer and is not part of standard PostgreSQL EXPLAIN output.

What it shows

Each cost breakdown is a list of reasons with their cost contribution:

Field	Description
Reason	What this portion of the cost represents
Cost	The numeric cost attributed to this reason

The reasons sum to the node’s Total Cost. In the tree view, IndeX-Ray renders these as a color-coded bar where each segment represents a different reason. Hovering over a segment shows the reason, its cost, and its percentage of the total.

Why it matters

A node’s Total Cost alone doesn’t tell you what to fix. Two nodes can have the same cost for completely different reasons — one might be dominated by I/O from reading heap pages, while the other is bottlenecked by CPU-intensive filtering. The breakdown reveals which component is the dominant contributor, which helps you choose the right optimization:

• High I/O cost — the node is reading many pages from disk or shared buffers. A more selective index or covering index (Index Only Scan) could reduce the pages touched.
• High CPU/filter cost — the node reads rows efficiently but discards many through filtering. A more targeted index that pushes the filter into the index condition could eliminate the wasted work.
• High startup cost — the node spends significant effort before returning its first row. This matters most for queries with LIMIT that only need early results.

Where it appears

Cost breakdowns can appear on any plan node, but are most actionable on scan nodes (Seq Scan, Index Scan, Bitmap Heap Scan, etc.) where you have direct control over access paths via indexes.

Cost breakdowns also appear within alternative plans, letting you compare not just the total cost of each rejected path but the shape of its cost — useful for understanding what makes an alternative more expensive than the chosen plan.

How it’s generated

The analyzer decomposes each node’s cost using PostgreSQL’s cost model parameters (seq_page_cost, random_page_cost, cpu_tuple_cost, etc.) and the table statistics it collects. This runs entirely on your machine inside the analyzer container.

All augmented fields are marked with an asterisk (*) in the UI and include a tooltip noting they are not part of standard PostgreSQL EXPLAIN output.