Skip scan gives an index another job, conditionally
PostgreSQL 18’s skip scan widened multicolumn index choices. Compare real query plans and write costs before removing a dedicated index from a workload.
By 
Paul. Architecture and infrastructure
A planner improvement should reopen an index decision, rather than settle it automatically. PostgreSQL 18's skip scan gives some multicolumn B-tree indexes a more useful path for queries that lack a leading equality condition. Whether that makes another index redundant depends on the workload. Keep the dedicated index until a comparison explains what the application would gain and lose by removing it.
Looking back from November 2026, PostgreSQL 18 Beta 1 was announced on 8 May 2025. The project asked users to try typical workloads and explicitly advised against production use of that beta. Its skip-scan highlight was an invitation to evaluate a preview. It was not a statement that a stable PostgreSQL 18 release had already shipped that week.
The missing leading condition still matters
A B-tree index orders entries by its keys. An index beginning with a region and then a customer reference naturally serves queries that constrain both. A query using only the customer reference has a different access problem. The database must find relevant entries without receiving a fixed region from the query.
The PostgreSQL 18 multicolumn-index documentation, consulted in November 2026, explains skip scan through repeated searches with internally generated equality conditions. It is generally attractive when there are few distinct values in the missing leading column, allowing most index pages to be skipped. Many distinct leading values can instead make a sequential scan preferable. This is versioned mechanism guidance, not a record of the application's May performance.
The region example is illustrative. If there are few regions, trying the relevant key range within each region may be useful. If the first key is effectively unique per row, the same intuition becomes weak. The existence of a later selective condition does not make the number of preceding groups irrelevant.
Even with a favorable key distribution, another index might offer a cheaper path for the most important query. A dedicated customer-reference index could avoid repeated searches. Its value depends on query frequency, latency needs and what rows or ordering the query requests. The new access path expands the comparison; it does not erase the alternatives.
Development history is not an application result
The selected historical evidence also includes an April 4 commit improving primitive-scan scheduling. It adjusts a heuristic used in skip scans and describes cases where scheduling matters. This is a specific implementation refinement. Calling it the release date, or the original introduction of the entire feature, would misread the record.
That refinement is also a reminder that an optimization includes cost decisions beneath the headline. The application receives the planner's chosen path for particular statistics and query conditions. It does not receive an unconditional promise to skip enough work on every execution. General feature availability and local plan quality need separate evidence.
For an evaluation, identify the exact database build and the query shapes under consideration. Retain representative parameter values and data distributions. Comparing a rare customer reference in one environment with a common reference in another would make the index decision difficult to interpret. Keep the comparison tied to the workload the service must actually support.
Compare the portfolio of indexes
The business reason to remove a genuinely redundant index is broader than read time. Every retained index occupies storage and can add maintenance work when data changes. Those are reasons to investigate consolidation. They are not measurements of savings for this application, and they cannot outweigh an important read regression merely because the index count becomes smaller.
A proposed review should compare plans, actual execution behavior and write costs with the candidate configurations. In a safe evaluation environment, plan inspection can show whether the intended path is selected; execution observations can then test whether the expected benefit appears. This article ran no database experiment and supplies no benchmark or recommended percentage threshold.
Keep other index duties in view. An index may support a constraint, an ordering requirement or a different query family. Showing that one lookup can use skip scan does not demonstrate that every responsibility of another index has been replaced. Name the index's jobs before judging it redundant.
Statistics and application demand can change after adoption. A distribution with few leading values today may become less favorable as the product grows. A removal decision should therefore leave behind the queries compared and the operational signal that would prompt reconsideration. Otherwise the team retains a slogan about skip scan while losing the reason its particular schema was acceptable.
A dedicated index may remain the best purchase
The strongest counterargument to consolidation is a frequent, latency-sensitive query for which the dedicated index remains predictably cheaper. Paying its storage and write costs can be rational. A database optimization does not create an obligation to minimize index count, especially when a slow lookup delays an important customer action.
Use skip scan as a reason to re-examine assumptions about leading keys. Retain an existing index when its measured role still justifies its costs, and remove it only when the whole workload supports that choice. For custom software development, ask for the compared queries and plans alongside the schema change. That evidence makes the decision reviewable when the data or the planner changes again.