Spell "parallel" correctly.

Per David Rowley.

src/backend/optimizer/README

@@ -938,7 +938,7 @@ often very limited due to the difficulty of avoiding pipeline stalls.
 Consequently, we do not currently attempt to generate query plans that
 use this technique.
 
-Instead, we focus on partitioning paralellism, which does not require
+Instead, we focus on partitioning parallelism, which does not require
 that the underlying table be partitioned.  It only requires that (1)
 there is some method of dividing the data from at least one of the base
 tables involved in the relation across multiple processes, (2) allowing

src/backend/optimizer/path/costsize.c

@@ -238,7 +238,7 @@ cost_seqscan(Path *path, PlannerInfo *root,
 		 * only one worker, the leader often makes a very substantial
 		 * contribution to executing the parallel portion of the plan, but as
 		 * more workers are added, it does less and less, because it's busy
-		 * reading tuples from the workers and doing whatever non-paralell
+		 * reading tuples from the workers and doing whatever non-parallel
 		 * post-processing is needed.  By the time we reach 4 workers, the
 		 * leader no longer makes a meaningful contribution.  Thus, for now,
 		 * estimate that the leader spends 30% of its time servicing each