Re: Should we warn against using too many partitions?

I suggest just minor variations on language.

On Thu, Jun 06, 2019 at 04:43:48PM +1200, David Rowley wrote:

>diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
>index cce1618fc1..ab26630199 100644
>--- a/doc/src/sgml/ddl.sgml
>+++ b/doc/src/sgml/ddl.sgml
>@@ -4674,6 +4675,76 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
>    </itemizedlist>
>    </para>
>   </sect2>
>+  
>+  <sect2 id="ddl-partitioning-declarative-best-practices">
>+   <title>Declarative Partitioning Best Practices</title>
>+
>+   <para>
>+    The choice of how to partition a table should be considered carefully as

Either say "How to partition consider should be .." or "The choice should MADE carefully" ?

>+   <para>
>+    One of the most critical design decisions will be the column or columns
>+    which you partition your data by.  Often the best choice will be to

by which ?

>+   <para>
>+    Choosing the number of partitions to divide the table into is also a

the TARGET number of partitions BY WHICH to divide the table ?

>+    critical decision to make.  Not having enough partitions may mean that
>+    indexes remain too large and that data locality remains poor which could
>+    result in poor cache hit ratios.  However, dividing the table into too
>+    many partitions can also cause issues.  Too many partitions can mean
>+    slower query planning times and higher memory consumption during both
>+    query planning and execution.  It's also important to consider what
>+    changes may occur in the future when choosing how to partition your table.
>+    For example, if you choose to have one partition per customer and you
>+    currently have a small number of large customers, what will the

have ONLY ?

>+    implications be if in several years you obtain a large number of small
>+    customers.  In this case, it may be better to choose to partition by
>+    <literal>HASH</literal> and choose a reasonable amount of partitions

reasonable NUMBER ?

>+   <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 thousand partitions fairly well,
>+    providing that the vast majority of them can be pruned during query

provided ?

I would say: "provided that typical queries prune all but a small number of
partitions during planning time".

>+    <command>DELETE</command> commands.  Also, even if most queries are
>+    able to prune a high number of partitions during query planning, it still

LARGE number?

>+    may be undesirable to have a large number of partitions as each partition

may still ?

>+    also will obtain a relation cache entry in each session which uses the

will require ?  Or occupy ?

>+   <para>
>+    With data warehouse type workloads it can make sense to use a larger
>+    number of partitions than with an OLTP type workload.  Generally, in data
>+    warehouses, query planning time is less of a concern as the majority of
>+    processing time is generally spent during query execution.  With either of

remove the 2nd "generally"

>+    these two types of workload, it is important to make the right decisions
>+    early as re-partitioning large quantities of data can be painstakingly

early COMMA ?

PAINFULLY slow

>+    When performance is critical, performing workload simulations to
>+    assist in making the correct decisions can be beneficial.  

I would say:
Simulations of the intended workload are beneficial for optimizing partitioning
strategy.

Thanks,
Justin