On 2016/09/02 15:22, Ashutosh Bapat wrote: >> >> >>> 2. A combination of constraints on the partitions should be applicable to >>> the parent. We aren't doing that. >> >> How about on seeing that a RELOPT_OTHER_MEMBER_REL is partitioned parent >> table, we can have get_relation_constraints() include a constant false >> clause in the list of constraints returned for >> relation_excluded_by_constraints() to process so that it is not included >> in the append result by way of constraint exclusion. One more option is >> to mark such rels dummy in set_rel_size(). >> >> > I am not complaining about having parent relation there. For the people who > are used to seeing the parent relation in the list of append relations, it > may be awkward. But +1 if we can do that. If we can't do that, we should at > least mark with an OR of all constraints on the partitions, so that > constraint exclusion can exclude it if there are conditions incompatible > with constraints. This is what would happen in inheritance case as well, if > there are constraints on the parent. In the above example, the parent table > would have constraints CHECK ((a >= 0 AND a < 250) OR (a >= 250 and a < > 500) OR (a >= 500 or a < 600)). It will probably get excluded, if > constraint exclusion is smart enough to understand ORing.
I guess constraint exclusion would be (is) smart enough to handle that correctly but why make it unnecessarily spend a *significant* amount of time on doing the proof (when we *know* we can just skip it). Imagine how long the OR list could get. By the way, my suggestion of just returning a constant false clause also does not work - neither in case of a query with restrictions (predicate has to be an OpExpr to go ahead with the proof which constant false clause is not) nor in case of a query without restrictions (proof is not performed at all). So, that one is useless.
Huh!
Getting rid of the parent table in the append list by other means may be a way to go. We know that the table is empty and safe to just drop.
Ok. Does a constraint (1 = 2) or something like that which is obviously false, help?
--
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company