Hello, On Thu, Aug 8, 2019 at 5:09 PM Amit Langote <amitlangot...@gmail.com> wrote: > > Hi Simon, > > On Thu, Aug 8, 2019 at 4:54 PM Simon Riggs <si...@2ndquadrant.com> wrote: > > On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera <alvhe...@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 algoithmic cost 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
