Lesson 8 of 12

Parallel Query: How PostgreSQL Splits Work Across Workers

Applies to PostgreSQL 13–17 Last reviewed May 2026 Grounded in source

The one thing to understand first

Historically each PostgreSQL query ran in a single backend process. Parallel query lets the planner split eligible work across multiple worker processes that execute parts of the plan concurrently, then combine results. The machinery lives in src/backend/executor/nodeGather.c, execParallel.c, and the parallel-aware scan nodes.

Parallelism is a cost-based decision, not a guarantee: the planner only goes parallel when the table is big enough to repay worker startup, and it can only launch as many workers as the shared pool has free. “Planned 4, launched 2” is the signature of a pool too small for your concurrency.

The Gather node

A parallel plan has a Gather (or Gather Merge) node. Below it is the parallel portion run by the leader plus its workers; above it is serial. At execution, the leader launches background workers, each runs its copy of the sub-plan, and produces tuples into a shared queue; Gather collects them. Gather Merge preserves <a class="sev1-termlink" href="https://thesev1database.com/glossary/pathkeys/" title="Pathkeys">sort order by merging each worker’s ordered stream.

This is a Pro lesson

Get every Learning Pathway and cookbook recipe — grounded in PostgreSQL source code, with diagnostics, fixes, and prevention for each topic.

Continue this lesson to learn:

  • Parallel-aware scans divide the data
  • How the planner decides
  • The worker pools
  • What blocks parallelism
  • Layer 3 — Watch it happen on your own database
  • Layer 4 — The levers this hands you
  • All 36 Learning Pathway lessons
  • 170+ cookbook recipes
  • Source-grounded diagnostics & fixes

Secure checkout Cancel anytime Source-grounded

Was this helpful?

← Back to 02 — Performance: Query & Index Mastery