Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 01679df

Browse files
committed
[Doc]: Update parallel.sgml by REL9_6_STABLE
1 parent ccd45f3 commit 01679df

File tree

1 file changed

+5
-19
lines changed

1 file changed

+5
-19
lines changed

doc/src/sgml/parallel.sgml

Lines changed: 5 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -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

0 commit comments

Comments
 (0)