Merge Append

A Merge Append combines several inputs that are each sorted on the same key, producing one globally-sorted stream — like Append, but order-preserving.

For ORDER BY over a partitioned table or UNION ALL where each child can supply rows in the required order (e.g. via per-partition indexes).

Efficient — it avoids a big final Sort by merging pre-sorted streams. Make sure each child has an index that provides the order, or it falls back to sorting.

Why it exists

Merge Append is the order-preserving sibling of Append. It takes several inputs that are each sorted on a common key and merges them into a single globally-sorted stream — exactly what an ORDER BY over a partitioned table needs when every partition can supply rows in the right order via its own index.

Without Merge Append, an ORDER BY over a partitioned table would force a big final Sort. Merge Append removes that.

Merge Append  (actual rows=… loops=1)
  Sort Key: created_at
  ->  Index Scan using events_2024_idx on events_2024
        Index Cond: …
  ->  Index Scan using events_2025_idx on events_2025
        Index Cond: …

What makes the planner pick it

Three conditions usually have to line up:

1. The query needs rows in some order (ORDER BY, or an upstream node that consumes sorted input).
2. The partitioned table's children each have an index that supplies that order.
3. The order matches the partition layout enough that merging is cheap.

If any of those fails — most often (2), because partition indexes don't lead with the ordering column — the planner falls back to Append + a Sort.

Pair it with LIMIT

Merge Append + LIMIT is one of the fastest patterns for "the latest N across partitions": each partition's index supplies its own latest rows; Merge Append merges them; LIMIT stops the whole thing after the first N. No big sort, no full scan.

• Append
• Sort
• Incremental Sort