Improvements regarding explanation of parallel execution and detailed node parameters

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/11/using-explain.html
Description:

Proposals for improvement of EXCPLAIN docu
https://www.postgresql.org/docs/current/using-explain.html:
1. There is no mentioning of how parallel execution gets depicted in the
execution plan.
-- how to interpret the actual_time with loops of a parallel executed
node?

2. I am logging execution plans with the help of the awsome auto_explain
plugin in JSON, scrape it from the log and transfer it to ELK stack for
further analysis. Therefore it would be quite helpful to have a reference
documentation about each and every individual node-type (Seq Scan, Hash
Join, Gather, Sort, Aggregate and so on.). Which are their optional fields,
which are mandatory, and most important, what is their semantic?

Kind regards

suspicious wording in pg_rewind docs

[Liudmila Mantrova]

Hi everyone,

While reviewing docs for [1] I came across a phrase in pg_rewind.sgml 
that seems confusing:


"... The point of divergence can be found either on the target timeline, 
the source timeline, or their common ancestor. In the typical failover 
scenario where the target cluster was shut down soon after the 
divergence, this is not a problem, but if the target cluster ran for a 
long time after the divergence, the old WAL files might no longer be 
present. In that case, they can be manually copied from the WAL archive 
to the |pg_wal| directory, or fetched on startup by configuring 
primary_conninfo 
 
or restore_command 
. 
"


While beginning of this paragraph talks about scanning target cluster 
WALs, the "or fetched on startup" part suggests that we are applying the 
source cluster WALs already, so I would simply remove it from here. To 
avoid source/target confusion, we could also add another hint that it's 
target WALs we are talking about.


Please consider the attached fix.

[1] 
https://www.postgresql.org/message-id/a3acff50-5a0d-9a2c-b3b2-ee36168955c1%40postgrespro.ru



--
Liudmila Mantrova
Technical writer at Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml
index 52a1caa..a7e1705 100644
--- a/doc/src/sgml/ref/pg_rewind.sgml
+++ b/doc/src/sgml/ref/pg_rewind.sgml
@@ -66,14 +66,12 @@ PostgreSQL documentation
can be found either on the target timeline, the source timeline, or their common
ancestor. In the typical failover scenario where the target cluster was
shut down soon after the divergence, this is not a problem, but if the
-   target cluster ran for a long time after the divergence, the old WAL
+   target cluster ran for a long time after the divergence, its old WAL
files might no longer be present. In that case, they can be manually
-   copied from the WAL archive to the pg_wal directory, or
-   fetched on startup by configuring  or
-   .  The use of
-   pg_rewind is not limited to failover, e.g.  a standby
-   server can be promoted, run some write transactions, and then rewinded
-   to become a standby again.
+   copied from the WAL archive to the pg_wal directory.
+   The use of pg_rewind is not limited to failover,
+   e.g. a standby server can be promoted, run some write transactions, and then
+   get rewound to become a standby again.