@@ -268,29 +268,70 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
268268 <title>Parallel Scans</title>
269269
270270 <para>
271- Currently, the only type of scan which has been modified to work with
272- parallel query is a sequential scan. Therefore, the driving table in
273- a parallel plan will always be scanned using a
274- <literal>Parallel Seq Scan</>. The relation's blocks will be divided
275- among the cooperating processes. Blocks are handed out one at a
276- time, so that access to the relation remains sequential. Each process
277- will visit every tuple on the page assigned to it before requesting a new
278- page.
271+ The following types of parallel-aware table scans are currently supported.
272+
273+ <itemizedlist>
274+ <listitem>
275+ <para>
276+ In a <emphasis>parallel sequential scan</>, the table's blocks will
277+ be divided among the cooperating processes. Blocks are handed out one
278+ at a time, so that access to the table remains sequential.
279+ </para>
280+ </listitem>
281+ <listitem>
282+ <para>
283+ In a <emphasis>parallel bitmap heap scan</>, one process is chosen
284+ as the leader. That process performs a scan of one or more indexes
285+ and builds a bitmap indicating which table blocks need to be visited.
286+ These blocks are then divided among the cooperating processes as in
287+ a parallel sequential scan. In other words, the heap scan is performed
288+ in parallel, but the underlying index scan is not.
289+ </para>
290+ </listitem>
291+ <listitem>
292+ <para>
293+ In a <emphasis>parallel index scan</> or <emphasis>parallel index-only
294+ scan</>, the cooperating processes take turns reading data from the
295+ index. Currently, parallel index scans are supported only for
296+ btree indexes. Each process will claim a single index block and will
297+ scan and return all tuples referenced by that block; other process can
298+ at the same time be returning tuples from a different index block.
299+ The results of a parallel btree scan are returned in sorted order
300+ within each worker process.
301+ </para>
302+ </listitem>
303+ </itemizedlist>
304+
305+ Only the scan types listed above may be used for a scan on the driving
306+ table within a parallel plan. Other scan types, such as parallel scans of
307+ non-btree indexes, may be supported in the future.
279308 </para>
280309 </sect2>
281310
282311 <sect2 id="parallel-joins">
283312 <title>Parallel Joins</title>
284313
285314 <para>
286- The driving table may be joined to one or more other tables using nested
287- loops or hash joins. The inner side of the join may be any kind of
288- non-parallel plan that is otherwise supported by the planner provided that
289- it is safe to run within a parallel worker. For example, it may be an
290- index scan which looks up a value taken from the outer side of the join.
291- Each worker will execute the inner side of the join in full, which for
292- hash join means that an identical hash table is built in each worker
293- process.
315+ Just as in a non-parallel plan, the driving table may be joined to one or
316+ more other tables using a nested loop, hash join, or merge join. The
317+ inner side of the join may be any kind of non-parallel plan that is
318+ otherwise supported by the planner provided that it is safe to run within
319+ a parallel worker. For example, if a nested loop join is chosen, the
320+ inner plan may be an index scan which looks up a value taken from the outer
321+ side of the join.
322+ </para>
323+
324+ <para>
325+ Each worker will execute the inner side of the join in full. This is
326+ typically not a problem for nested loops, but may be inefficient for
327+ cases involving hash or merge joins. For example, for a hash join, this
328+ restriction means that an identical hash table is built in each worker
329+ process, which works fine for joins against small tables but may not be
330+ efficient when the inner table is large. For a merge join, it might mean
331+ that each worker performs a separate sort of the inner relation, which
332+ could be slow. Of course, in cases where a parallel plan of this type
333+ would be inefficient, the query planner will normally choose some other
334+ plan (possibly one which does not use parallelism) instead.
294335 </para>
295336 </sect2>
296337