Hi Simon,
On Thu, Aug 8, 2019 at 4:54 PM Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>> Well, yes, avoiding that is the point of this commit also: we were
>> scanning some partitions for some queries, after this patch we're
>> supposed not to.
>
>
> Understood
>
> My concern was about the additional execution time caused when there would be no benefit, especially if the
algoithmiccost is O(N) or similar (i.e. worse than O(k))
Note that we apply constraint exclusion only to the (sub-partitioned)
parent, not to all partitions, so the cost is not O(N) in the number
of partitions. The idea is that if the parent is excluded, all of its
partitions are. We normally wouldn't need to use constrain exclusion,
because partition pruning can handle most cases. What partition
pruning can't handle sufficiently well though is the case where a
clause set that contradicts the partition constraint is specified --
while all non-default partitions are correctly pruned, the default
partition is not. Using constraint exclusion is a workaround for that
deficiency of the partition pruning logic.
Thanks,
Amit