On Mon, Sep 25, 2017 at 3:34 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote:
> Thanks for looking at the patches and the comments. > It's not clear to me whether get_rel_partitions() itself, as it is, is > callable from outside the planner, because its signature contains > RelOptInfo. We have the RelOptInfo in the signature, because we want to > mark certain fields in it so that latter planning steps can use them. So, > get_rel_partitions()'s job is not just to match clauses and find > partitions, but also to perform certain planner-specific tasks of > generating information that the later planning steps will want to use. > That may turn out to be unnecessary, but until we know that, let's not try > to export get_rel_partitions() itself out of the planner. > > OTOH, the function that your refactoring patch separates out to match > clauses to partition keys and extract bounding values seems reusable > outside the planner and we should export it in such a way that it can be > used in the executor. Then, the hypothetical executor function that does > the pruning will first call the planner's clause-matching function, > followed by calling get_partitions_for_keys() in partition.c to get the > selected partitions. Thanks for your reply. Actually, we are still planning to call get_matching_clause at the optimizer time only. Since we can not use get_rel_partitions function directly for runtime pruning because it does all the work (find matching clause, create minkey and maxkey and call get_partitions_for_keys) during planning time itself. For runtime pruning, we are planning to first get_matching_clause function during optimizer time to identify the clause which is matching with partition keys, but for PARAM_EXEC case we can not depend upon baserelrestriction instead we will get the from join clause, that's the reason I have separated out get_matching_clause. But it will still be used during planning time. 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. And, finally at runtime when we get the PARAM value we can prepare minkey and maxkey and call get_partitions_for_keys function. -- 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
