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
* 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