On 2017/09/28 13:58, Dilip Kumar wrote:
> On Wed, Sep 27, 2017 at 6:52 AM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>
> I was looking into the latest patch set, seems like we can reuse some
> more code between this path and runtime pruning[1]
>
> + foreach(lc1, matchedclauses[i])
> + {
> + Expr *clause = lfirst(lc1);
> + Const *rightop = (Const *) get_rightop(clause);
> + Oid opno = ((OpExpr *) clause)->opno,
> + opfamily = rel->part_scheme->partopfamily[i];
> + StrategyNumber strategy;
> +
> + strategy = get_op_opfamily_strategy(opno, opfamily);
> + switch (strategy)
> + {
> + case BTLessStrategyNumber:
> + case BTLessEqualStrategyNumber:
> + if (need_next_max)
> + {
> + maxkeys[i] = rightop->constvalue;
> + if (!maxkey_set[i])
> + n_maxkeys++;
> + maxkey_set[i] = true;
> + max_incl = (strategy == BTLessEqualStrategyNumber);
> + }
> + if (strategy == BTLessStrategyNumber)
> + need_next_max = false;
>
> I think the above logic is common between this patch and the runtime
> pruning. I think we can make
> a reusable function. Here we are preparing minkey and maxkey of Datum
> because we can directly fetch rightop->constvalue whereas for runtime
> pruning we are making minkeys and maxkeys of Expr because during
> planning time we don't have the values for the Param. I think we can
> always make these minkey, maxkey array of Expr and later those can be
> processed in whatever way we want it. So this path will fetch the
> constval out of Expr and runtime pruning will Eval that expression at
> runtime.
I think that makes sense. In fact we could even move the minkey/maxkey
collection code to match_clauses_to_partkey() itself. No need for a
different function and worrying about defining a separate interface for
the same. We match clauses exactly because we want to extract the
constant or param values out of them. No need to do the two activities
independently and in different places.
> Does this make sense or it will cause one level of extra processing
> for this path i.e converting the Expr array to CONST array?
Hm, it's not such a big cost to pay I'd think.
I will update the planner patch accordingly.
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers