Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, Apr 26, 2018 at 07:29:37PM +1200, David Rowley wrote:
> On 25 April 2018 at 09:59, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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