On Thu, Sep 28, 2017 at 1:44 PM, Amit Langote <langote_amit...@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
