Merge pull request #6401 from EnterpriseDB/docs/edits_to_pgd_pr6394

Edits to Docs 291 - Add PGD comparison matrix #6394

product_docs/docs/pgd/5.6/overview/architecture-and-performance.mdx

@@ -1,7 +1,7 @@
 ---
 title: "PGD overview - architecture and performance"
 navTitle: Architecture and performance
-description: EDB Postgres Distributed architectural options and performance characteristics, including always-on architectures, supported Postgres database servers, and characteristics affecting performance
+description: EDB Postgres Distributed architectural options and performance characteristics, including Always-on architectures, supported Postgres database servers, and characteristics affecting performance.
 deepToC: true
 redirects: 
   - bdr
@@ -19,7 +19,7 @@ The Always-on architectures are built from either one group in a single location
 
 Tables are created across both groups, so any change goes to all nodes, not just to nodes in the local group.
 
-One node in each group is selected as the group's write leader. Proxies then direct application writes and queries to the write leader. The other nodes are replicas of the write leader. If, at any point, the write leader is seen to be unavailable, the remaining nodes in the group select a new write leader from the group the proxies direct traffic to that node. Scalability isn't the goal of this architecture.
+One node in each group is selected as the group's write leader. Proxies then direct application writes and queries to the write leader. The other nodes are replicas of the write leader. If, at any point, the write leader is seen to be unavailable, the remaining nodes in the group select a new write leader from the group and the proxies direct traffic to that node. Scalability isn't the goal of this architecture.
 
 Since writes are mainly to only one node, the possibility of contention between nodes is reduced to almost zero. As a result, performance impact is much reduced.
 

product_docs/docs/pgd/5.6/overview/basic-architecture.mdx

@@ -1,15 +1,15 @@
 ---
 title: "PGD Overview - PGD's basic architecture"
 navTitle: Basic architecture
-description: An overview of EDB Postgres Distributed's basic architecture, including groups, multiple masters, mesh topology, logical replication, connection management, and high availability
+description: An overview of EDB Postgres Distributed's basic architecture, including groups, multiple masters, mesh topology, logical replication, connection management, and high availability.
 deepToC: true
 redirects: 
   - bdr
 ---
 
 EDB Postgres Distributed (PGD) provides multi-master replication and data distribution with advanced conflict management, data-loss protection, and [throughput up to 5X faster than native logical replication](https://www.enterprisedb.com/blog/performance-improvements-edb-postgres-distributed). It also enables distributed Postgres clusters with high availability up to five 9s.
 
-PGD provides loosely coupled, multimaster logical replication using a mesh topology. This means that you can write to any server and the changes are sent directly, row-by-row, to all the other servers that are part of the same PGD group.
+PGD provides loosely coupled, multimaster logical replication using a mesh topology. This means that you can write to any server and the changes are sent directly, row by row, to all the other servers that are part of the same PGD group.
 
 By default, PGD uses asynchronous replication, applying changes on the peer nodes only after the local commit. Multiple synchronous replication options are also available.
 
@@ -37,7 +37,7 @@ PGD is structured around a mesh network where every node connects to every other
 
 ### Logical replication
 
-Logical replication is a method of replicating data rows and their changes based on their replication identity (usually a primary key). We use the term logical in contrast to physical replication, which uses exact block addresses and byte-by-byte replication. Index changes aren't replicated, thereby avoiding write amplification and reducing bandwidth.
+Logical replication is a method of replicating data rows and their changes based on their replication identity (usually a primary key). We use the term *logical* in contrast to *physical* replication, which uses exact block addresses and byte-by-byte replication. Index changes aren't replicated, thereby avoiding write amplification and reducing bandwidth.
 
 Logical replication starts by copying a snapshot of the data from the source node. Once that's done, later commits are sent to other nodes as they occur in real time. Changes are replicated without executing SQL again, so the exact data written is replicated quickly and accurately.
 
@@ -61,4 +61,4 @@ Replication continues between currently connected nodes even if one or more node
 
 Nodes can run different release levels, negotiating the required protocols to communicate. As a result, EDB Postgres Distributed clusters can use rolling upgrades, even for [major versions](../upgrades/upgrading_major_rolling/) of database software.
 
-DDL is replicated across nodes by default. DDL execution can be user controlled to allow rolling application upgrades, if desired.
+DDL is replicated across nodes by default. If you want, you can control DDL execution to allow rolling application upgrades.

product_docs/docs/pgd/5.6/overview/compared.mdx

@@ -1,7 +1,7 @@
 ---
 title: PGD compared
 navTitle: Compared
-description: A comparison of EDB Postgres Distributed with other replication solutions, including pglogical 2, PG Builtin Logical Replication, and PGD Managed
+description: A comparison of EDB Postgres Distributed with other replication solutions, including pglogical 2, PG Builtin Logical Replication, and PGD Managed.
 ---
 
 The following table compares EDB Postgres Distributed with other replication solutions.