Hello,
On Thu, Aug 8, 2019 at 5:09 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> 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.
>
Besides that, the additional code will not be executed if people don't
define any default partition in the latest patch Amit proposed. So I think
this patch has no effect such as Simon's concern.
I looked at Amit's patches and found it worked correctly.
--
Best regards,
Yuzuko Hosoya
NTT Open Source Software Center