@@ -277,7 +277,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
277277 scan</emphasis>, the cooperating processes take turns reading data from the
278278 index. Currently, parallel index scans are supported only for
279279 btree indexes. Each process will claim a single index block and will
280- scan and return all tuples referenced by that block; otherprocess can
280+ scan and return all tuples referenced by that block; otherprocesses can
281281 at the same time be returning tuples from a different index block.
282282 The results of a parallel btree scan are returned in sorted order
283283 within each worker process.
@@ -410,7 +410,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
410410 involve appending multiple results sets can therefore achieve
411411 coarse-grained parallelism even when efficient partial plans are not
412412 available. For example, consider a query against a partitioned table
413- which canbe only be implemented efficiently by using an index that does
413+ which can only be implemented efficiently by using an index that does
414414 not support parallel scans. The planner might choose a <literal>Parallel
415415 Append</literal> of regular <literal>Index Scan</literal> plans; each
416416 individual index scan would have to be executed to completion by a single
