Hi. At Tue, 9 Apr 2019 16:41:47 +0900, "Yuzuko Hosoya" <hosoya.yuz...@lab.ntt.co.jp> wrote in <00cf01d4eea7$afa43370$0eec9a50$@lab.ntt.co.jp> > > So still it is wrong that the new code is added at the beginning of the > > loop on clauses in > > gen_partprune_steps_internal. > > > > > If partqual results true and the clause > > > is long, the partqual is evaluated uselessly at every recursion. > > > > > > Maybe we should do that when we find that the current clause doesn't > > > match part attributes. Specifically just after the for loop "for (i = > > > 0 ; i < part_scheme->partnattrs; i++)". > > > I think we should check whether WHERE clause contradicts partition > constraint even when the clause matches part attributes. So I moved
Why? If clauses contains a clause on a partition key, the clause is involved in determination of whether a partition survives or not in ordinary way. Could you show how or on what configuration (tables and query) it happens that such a matching clause needs to be checked against partqual? The "if (partconstr)" block uselessly runs for every clause in the clause tree other than BoolExpr. If we want do that, isn't just doing predicate_refuted_by(partconstr, clauses, false) sufficient before looping over clauses? > "if (partqual)" block to the beginning of the loop you mentioned. > > I'm attaching the latest version. Could you please check it again? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
