On Thu, Apr 26, 2018 at 07:29:37PM +1200, David Rowley wrote: > On 25 April 2018 at 09:59, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > Amit Langote wrote: > >> Although the config.sgml coverage of the new capabilities seems pretty > >> good, some may find their being mentioned in 5.10 Table Partitioning > >> helpful. Or if we don't want to hijack 5.10.4, maybe create a 5.10.5. > > > > Can you (or someone) describe what would that section contain? > > I've drafted and attached a patch of how I think this should look. > Likely it will need some tweaking, but it is probably a good starting > point for discussion.
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 34da0d8d57..89735b4804 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml + <para> + Unlike constraint exclusion, partition pruning can be performed much more + quickly as it does not have to scan each individual partition's metadata quickly COMMA But actually I suggest: Partition pruning is much more efficient than constraint exclusion, since pruning avoids scanning each partition's metadata... + Partition Pruning is also more powerful than constraint exclusion as + partition pruning is not something that is performed only during the remove "something that is" ? Or just merge into the next sentence. Note: Amit and David commented on this previously. + planning of a given query. In certain cases, partition pruning may also + be performed during execution of the query as well. This allows pruning "also" is redundant with "as well" + to be performed using values which are unknown during query planning, for could say "are not yet known" + The partition pruning which is performed during execution is done so at + either one or both of the following times: remove "either" ? + During initialization of the query plan. Partition pruning can be + initialization phase of execution. If partition pruning can be + performed here then there is the added benefit of not having to here COMMA + initialize partitions which are pruned. Partitions which are pruned + during this stage will not show up in the query's + During actual execution of the query plan. Partition pruning may also Remove "actual" ? + be performed here to remove partitions using values which are only known + during actual query execution. This includes values from subqueries and + values from execution time parameters such as ones from parameterized execution-time? s/ones/those/ + partition column or expression changes. In order to determine if + partitions were pruned at this stage requires careful inspection of the + <literal>nloops</literal> property in the + <command>EXPLAIN ANALYZE</command> output. s/In order to determine/Determining/ + <para> + Currently, partition pruning of partitions during the planning of an s/partition //1 (just "pruning of partitions") + <command>UPDATE</command> or <command>DELETE</command> command are s/are/is/ + internally implemented using the constraint exclusion method. Only remove "internally"? + <command>SELECT</command> uses the faster partition pruning method. Also Also COMMA + partition pruning performed during execution is only done so for the Remove "so". Justin
