Re: path toward faster partition pruning

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: path toward faster partition pruning
Date: 2017-09-28 08:14:56
Message-ID: c00e614f-74bd-6479-3c0d-30325a9257c7@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017/09/28 13:58, Dilip Kumar wrote:
> On Wed, Sep 27, 2017 at 6:52 AM, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2017-09-28 08:16:56 Re: path toward faster partition pruning
Previous Message Amit Langote 2017-09-28 07:20:39 Re: [HACKERS] PartitionSchemaData & partcollation (Re: pgsql: Associate partitioning information with each RelOptInfo.)