On Tue, Sep 26, 2017 at 2:45 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/25 20:21, Dilip Kumar wrote:
> I see. So, in the run-time pruning case, only the work of extracting > bounding values is deferred to execution time. Matching clauses with the > partition key still occurs during planning time. Only that the clauses > that require run-time pruning are not those in rel->baserestrictinfo. Right. > >> After separating out the matching clause we will do somewhat similar >> processing what "get_rel_partitions" is doing. But, at optimizer time >> for PARAM we will not have Datum values for rightop, so we will keep >> track of the PARAM itself. > > I guess information about which PARAMs map to which partition keys will be > kept in the plan somehow. Yes. > >> And, finally at runtime when we get the PARAM value we can prepare >> minkey and maxkey and call get_partitions_for_keys function. > > Note that get_partitions_for_keys() is not planner code, nor is it bound > with any other planning code. It's callable from executor without much > change. Maybe you already know that though. Yes, Right. -- 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
