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

On 2018/04/26 16:29, 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.

Thanks David for drafting this. I see that you have not included the
description of other partitioning-based optimizations such partitionwise
plans that the planner can now consider. I guess that's fine though, as
Alvaro also seemed a bit doubtful about the value of providing the
description of those optimizations in this part of the documentation (that
is, in 5.10 Table Partitioning).

About the patch in general, it seems like the newly added documentation
talks about "Partition Pruning" as something that *replaces* constraint
exclusion. But, I think "Partition Pruning" is not the thing that
replaces constraint exclusion. We used to do partition pruning even
before and used constraint exclusion as the algorithm. What's new is the
algorithm that we now use to perform partition pruning for declaratively
partitioned tables. Also, the characteristics of the new algorithm are
such that it can now be used in more situations, thus making it more
useful than the earlier method of partition pruning, so that new features
like runtime pruning could be realized. I like that the patch adds
various details about the new pruning features, but think that the wording
and the flow could be improved a bit.

What do you think?

Thanks,
Amit