On Thu, Sep 28, 2017 at 1:44 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers