On Fri, Sep 2, 2016 at 12:23 PM, Amit Langote <langote_amit...@lab.ntt.co.jp > wrote:
> 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
