Commit d5b6b651 authored by Amit Kapila's avatar Amit Kapila

Fix typos in parallel query docs.

Reported-by: Jon Jensen
Author: Jon Jensen
Reviewed-by: Amit Kapila and Robert Haas
Backpatch-through: 10
Discussion: https://postgr.es/m/nycvar.YSQ.7.76.1912301807510.9899@ybpnyubfg
parent 0c41c83d
...@@ -277,7 +277,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; ...@@ -277,7 +277,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
scan</emphasis>, the cooperating processes take turns reading data from the scan</emphasis>, the cooperating processes take turns reading data from the
index. Currently, parallel index scans are supported only for index. Currently, parallel index scans are supported only for
btree indexes. Each process will claim a single index block and will btree indexes. Each process will claim a single index block and will
scan and return all tuples referenced by that block; other process can scan and return all tuples referenced by that block; other processes can
at the same time be returning tuples from a different index block. at the same time be returning tuples from a different index block.
The results of a parallel btree scan are returned in sorted order The results of a parallel btree scan are returned in sorted order
within each worker process. within each worker process.
...@@ -410,7 +410,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%'; ...@@ -410,7 +410,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
involve appending multiple results sets can therefore achieve involve appending multiple results sets can therefore achieve
coarse-grained parallelism even when efficient partial plans are not coarse-grained parallelism even when efficient partial plans are not
available. For example, consider a query against a partitioned table available. For example, consider a query against a partitioned table
which can be only be implemented efficiently by using an index that does which can only be implemented efficiently by using an index that does
not support parallel scans. The planner might choose a <literal>Parallel not support parallel scans. The planner might choose a <literal>Parallel
Append</literal> of regular <literal>Index Scan</literal> plans; each Append</literal> of regular <literal>Index Scan</literal> plans; each
individual index scan would have to be executed to completion by a single individual index scan would have to be executed to completion by a single
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment