Alternative Plans
When you open a query’s explain plan in IndeX-Ray, some plan nodes include an Alternatives section marked with an asterisk (*). This is not part of standard PostgreSQL EXPLAIN output — it is augmented by the analyzer to show the other execution strategies the planner evaluated and rejected for that node.
What it shows
Section titled “What it shows”Each alternative includes:
| Field | Description |
|---|---|
| Node Type | The execution strategy that was considered (e.g. Index Scan, Seq Scan, Bitmap Heap Scan) |
| Index Name | The index involved, if applicable |
| Total Cost | The planner’s estimated cost for this alternative |
| Prune Reason | Why the planner rejected this path in favor of the chosen one |
| Cost Breakdown | A breakdown of what contributes to the total cost (when available) |
Alternatives are sorted by cost, cheapest first.
Why it matters
Section titled “Why it matters”Standard EXPLAIN only shows the plan the optimizer chose. It doesn’t tell you what else it considered or how close the decision was. Alternatives fill that gap:
- Close calls — if a rejected Index Scan is only slightly more expensive than the chosen Seq Scan, a small schema change (like adjusting statistics targets or adding a partial index) might tip the balance.
- Missing indexes — if every alternative is a Seq Scan variant, there may be no suitable index for the planner to consider. Check ineligible indexes to see if existing indexes were ruled out, or consider creating a new one.
- Index overhead — if an Index Scan alternative was rejected because its cost is higher than a Seq Scan, the table may be small enough that sequential access is genuinely faster. Adding more indexes won’t help here.
Where alternatives appear
Section titled “Where alternatives appear”Alternatives are most commonly shown on scan nodes — the leaf nodes of a plan tree where the planner must choose how to access a table:
- Seq Scan
- Index Scan
- Index Only Scan
- Bitmap Heap Scan
These are the nodes where PostgreSQL evaluates multiple access paths and picks the cheapest. Higher-level nodes (joins, sorts, aggregates) are typically determined by the access paths chosen below them.
Prune reasons
Section titled “Prune reasons”Every alternative was ultimately rejected because the planner estimated a higher cost than the chosen path. However, PostgreSQL doesn’t always compute a full cost estimate for every candidate — it uses heuristics to discard obviously unsuitable paths early, which keeps planning time fast even when many indexes exist.
The Prune Reason field reflects this. Some alternatives were eliminated after a full cost comparison, while others were shortcut out because a heuristic determined they couldn’t possibly win. For example, an index whose columns have no relevance to the query’s WHERE clause can be ruled out without estimating I/O or CPU costs at all — these indexes appear as ineligible rather than as alternatives.
This distinction is useful when reading alternatives: a path pruned by heuristic was never a real contender, while a path pruned after costing may be worth investigating — especially if its cost is close to the winner.
How they’re generated
Section titled “How they’re generated”The alternatives are computed by the analyzer, not by PostgreSQL’s standard EXPLAIN. The analyzer examines the planner’s decision process for each node and surfaces the paths that were evaluated but not selected. 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.