Re: path toward faster partition pruning

On Thu, Sep 28, 2017 at 1:44 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> On 2017/09/28 13:58, Dilip Kumar wrote:

>> 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.
>

+1

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com