diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index c80d42d..b8f33b3 100644
--- a/doc/src/sgml/parallel.sgml
+++ b/doc/src/sgml/parallel.sgml
@@ -148,7 +148,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
         which the system thinks that partial or incremental execution might
         occur, no parallel plan is generated. For example, a cursor created
         using <link linkend="sql-declare">DECLARE CURSOR</link> will never use
-        a parallel plan. Similarly, a PL/pgsql loop of the form
+        a parallel plan. Similarly, a PL/pgSQL loop of the form
         <literal>FOR x IN query LOOP .. END LOOP</literal> will never use a
         parallel plan, because the parallel query system is unable to verify
         that the code in the loop is safe to execute while parallel query is
@@ -189,7 +189,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     Even when parallel query plan is generated for a particular query, there
     are several circumstances under which it will be impossible to execute
     that plan in parallel at execution time.  If this occurs, the leader
-    will execute the portion of the plan between below the <literal>Gather</>
+    will execute the portion of the plan below the <literal>Gather</>
     node entirely by itself, almost as if the <literal>Gather</> node were
     not present.  This will happen if any of the following conditions are met:
   </para>
@@ -339,7 +339,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
 
   <para>
     When executing a parallel plan, you can use <literal>EXPLAIN (ANALYZE,
-    VERBOSE)</literal> will display per-worker statistics for each plan node.
+    VERBOSE)</literal> to display per-worker statistics for each plan node.
     This may be useful in determining whether the work is being evenly
     distributed between all plan nodes and more generally in understanding the
     performance characteristics of the plan.
@@ -421,7 +421,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
   <para>
     Functions and aggregates must be marked <literal>PARALLEL UNSAFE</> if
     they write to the database, access sequences, change the transaction state
-    even temporarily (e.g. a PL/pgsql function which establishes an
+    even temporarily (e.g. a PL/pgSQL function which establishes an
     <literal>EXCEPTION</> block to catch errors), or make persistent changes to
     settings.  Similarly, functions must be marked <literal>PARALLEL
     RESTRICTED</> if they access temporary tables, client connection state,