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

diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index af5d48a5c7943e1d61103f1e08d19255b8e5b86a..95306287e2030b186e941170da01c9a732cad5b7 100644 (file)
--- a/doc/src/sgml/parallel.sgml
+++ b/doc/src/sgml/parallel.sgml
@@ -277,7 +277,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
         scan</emphasis>, the cooperating processes take turns reading data from the
         index.  Currently, parallel index scans are supported only for
         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.
         The results of a parallel btree scan are returned in sorted order
         within each worker process.
@@ -410,7 +410,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     involve appending multiple results sets can therefore achieve
     coarse-grained parallelism even when efficient partial plans are not
     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
     Append</literal> of regular <literal>Index Scan</literal> plans; each
     individual index scan would have to be executed to completion by a single