diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README
index f9967c0828c768860896bb315076c77bb352cd6a..7ecf8c8f0cc38bc9573db4f8b629332b0904cf86 100644
--- a/src/backend/optimizer/README
+++ b/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
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index ffff3c012827af32e9368ffd45d406fef9d6edc1..5350329998a8e22e9778091d24bd57255b0fd724 100644
--- a/src/backend/optimizer/path/costsize.c
+++ b/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