@@ -288,25 +288,11 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
288288 <sect2 id="parallel-aggregation">
289289 <title>Parallel Aggregation</title>
290290 <para>
291- It is not possible to perform the aggregation portion of a query entirely
292- in parallel. For example, if a query involves selecting
293- <literal>COUNT(*)</>, each worker could compute a total, but those totals
294- would need to combined in order to produce a final answer. If the query
295- involved a <literal>GROUP BY</> clause, a separate total would need to
296- be computed for each group. Even though aggregation can't be done entirely
297- in parallel, queries involving aggregation are often excellent candidates
298- for parallel query, because they typically read many rows but return only
299- a few rows to the client. Queries that return many rows to the client
300- are often limited by the speed at which the client can read the data,
301- in which case parallel query cannot help very much.
302- </para>
303-
304- <para>
305- <productname>&productname;</> supports parallel aggregation by aggregating
306- twice. First, each process participating in the parallel portion of the
307- query performs an aggregation step, producing a partial result for each
308- group of which that process is aware. This is reflected in the plan as
309- a <literal>PartialAggregate</> node. Second, the partial results are
291+ <productname>&productname;</> supports parallel aggregation by aggregating in
292+ two stages. First, each process participating in the parallel portion of
293+ the query performs an aggregation step, producing a partial result for
294+ each group of which that process is aware. This is reflected in the plan
295+ as a <literal>Partial Aggregate</> node. Second, the partial results are
310296 transferred to the leader via the <literal>Gather</> node. Finally, the
311297 leader re-aggregates the results across all workers in order to produce
312298 the final result. This is reflected in the plan as a