Hello,
Please consider committing a couple of corrections for parallel.sgml.
Best regards,
Alexander
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,
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
