diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index b628cac2d3cae974ca4640d81bc3296a8c76eba1..a49a14cac1d5f4ec8a2640d567de4c6d168e4fcd 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -4113,12 +4113,12 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
    <para>
     It is also important to consider the overhead of partitioning during
     query planning and execution.  The query planner is generally able to
-    handle partition hierarchies up a few hundred partitions fairly well,
-    provided that typical queries allow the query planner to prune all but a
-    small number of partitions.  Planning times become longer and memory
+    handle partition hierarchies with up to a few hundred partitions fairly
+    well, provided that typical queries allow the query planner to prune all
+    but a small number of partitions.  Planning times become longer and memory
     consumption becomes higher as more partitions are added.  This is
     particularly true for the <command>UPDATE</command> and
-    <command>DELETE</command> commands. Another reason to be concerned about
+    <command>DELETE</command> commands.  Another reason to be concerned about
     having a large number of partitions is that the server's memory
     consumption may grow significantly over a period of time, especially if
     many sessions touch large numbers of partitions.  That's because each