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