A multicolumn B-tree does not always require an equality condition on its first column to avoid reading the entire index. PostgreSQL can use skip scan to perform repeated targeted searches when a predicate constrains a later column and the planner estimates that repositioning will bypass enough index entries.
Consider an index whose key order is (region, created_at):
CREATE INDEX orders_region_created_at_idx
ON orders (region, created_at);A query that filters only created_at has no explicit condition on region:
SELECT id, region, created_at
FROM orders
WHERE created_at >= TIMESTAMPTZ '2026-09-15 00:00:00+00'
AND created_at < TIMESTAMPTZ '2026-09-16 00:00:00+00';The conventional left-prefix rule still describes the normal scan boundary: without a constraint on region, a single continuous scan cannot jump directly to one narrow created_at interval covering the whole index. Skip scan changes the execution shape by introducing repeated searches within the B-tree.
Skip scan synthesizes prefix searches
For an index on (x, y) and a condition such as y = 7700, PostgreSQL can internally search as though it had a series of conditions shaped like:
x = first_value AND y = 7700
x = second_value AND y = 7700
x = third_value AND y = 7700These are not SQL predicates added to the query. They describe how the B-tree scan navigates. The executor repositions to the relevant portion of each prefix group instead of walking every entry between groups.
The useful property is ordered grouping. Entries with the same leading key are adjacent, and the later key is ordered within that group. Once PostgreSQL has established a prefix value, the later-column condition can provide a precise search position inside that group.
This does not turn a multicolumn index into an index with arbitrary key order. The repeated searches have a cost, and their count depends on the prefix values that must be considered.
Prefix cardinality shapes the cost
Skip scan is most attractive when the omitted leading column has relatively few distinct values. If region has a small set of values, repeating a targeted created_at search for each region can avoid large portions of the index.
The shape changes when the leading column has many distinct values. Repositioning for a large number of groups can approach the work of scanning broad portions of the index, while adding search overhead. In that case, the planner may choose another access path, including a sequential scan.
Statistics therefore affect whether skip scan appears in a plan. The planner needs estimates for the number of prefix groups and the selectivity of the later-column predicate. The existence of a suitable multicolumn B-tree alone does not guarantee that skip scan will be selected.
Later predicates can trigger selective repositioning
Skip scan is not limited to queries that omit every leading-column condition. It can also reposition within a partially constrained index.
With an index on (a, b, c) and this predicate:
WHERE a = 5
AND b >= 42
AND c < 77the equality on a fixes the first key. The range on b establishes a broad span, while the condition on c may make parts of individual b groups irrelevant.
When the planner expects a benefit, the scan can restart at a later position instead of reading through entries that cannot satisfy the c condition. In effect, the executor uses the ordered key structure to move between useful regions inside the already constrained a = 5 portion.
This distinction matters when reading plans conceptually. A predicate shown as an index condition does not by itself state how much of the physical index must be traversed. Navigation strategy determines whether the executor walks through intervening entries or performs additional searches to bypass them.
Skip scan does not erase index key order
An index on (region, created_at) and an index on (created_at, region) still serve different access patterns. The second index can directly bound a query on created_at using its leading key. The first may need repeated searches across region groups.
That difference affects more than lookup cost. B-tree key order also controls the ordering available from an index scan, the usefulness of leading-column predicates, and the size of the key ranges touched by common queries.
Skip scan can make an existing multicolumn index useful for a predicate that omits a prefix equality condition, but it is not a reason to ignore workload-driven key ordering. A dedicated index with the queried column first can still provide a simpler and cheaper path when that access pattern is frequent enough to justify another index.
Planner choice remains cost based
PostgreSQL does not expose skip scan as a separate SQL operation that an application requests. It is an optimization available to B-tree index scans when the planner estimates repeated navigation to be cheaper than the alternatives.
That means its presence can vary with data distribution, table size, statistics, predicate selectivity, and competing indexes. A query that benefits from skip scan on one data set can receive a different plan after the distribution of the leading key changes.
The practical boundary is precise: skip scan expands the set of cases in which a multicolumn B-tree can avoid broad index traversal, but only when repeated repositioning discards enough index entries to pay for those searches. Index key order remains the primary structure; skip scan is a navigation strategy within it.