Gather and Parallel Query: Why Actual Rows Are Per Worker, Not Per Query
PostgreSQL can split a large scan or join across several background workers, and the plan shows this as a Gather or Gather Merge node collecting their output. The trap when reading such a plan is that the row counts and times below the Gather are per-worker averages, so a step that says 200,000 rows across three workers really produced closer to 600,000. Parallelism helps big scans and aggregations and does nothing for a query that touches few rows, and workers are a limited pool shared across the whole server.
Questions this Concept answers
- Why must row counts below a `Gather` be read differently?
Reading Parallel Plans Correctly
PostgreSQL normally runs one query on one CPU core, so since 9.6 it can split big scans, joins and aggregates across extra worker processes, shown in the plan as a Gather or Gather Merge node. The ca…