On Fri, Sep 15, 2017 at 2:20 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/15 11:16, Amit Langote wrote:
Thanks for the updated patch. I was going through the logic of get_rel_partitions in 0002 as almost similar functionality will be required by runtime partition pruning on which Beena is working. The only difference is that here we are processing the "rel->baserestrictinfo" and in case of runtime pruning, we also need to process join clauses which are pushed down to appendrel. So can we make some generic logic which can be used for both the patches. So basically, we need to do two changes 1. In get_rel_partitions instead of processing the "rel->baserestrictinfo" we can take clause list as input that way we can pass any clause list to this function. 2. Don't call "get_partitions_for_keys" routine from the "get_rel_partitions", instead, get_rel_partitions can just prepare minkey, maxkey and the caller of the get_rel_partitions can call get_partitions_for_keys, because for runtime pruning we need to call get_partitions_for_keys at runtime. After these changes also there will be one problem that the get_partitions_for_keys is directly fetching the "rightop->constvalue" whereas, for runtime pruning, we need to store rightop itself and calculate the value at runtime by param evaluation, I haven't yet thought how can we make this last part generic. -- 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
