Hi: I recently found a use case like this. SELECT * FROM p, q WHERE p.partkey = q.colx AND (q.colx = $1 OR q.colx = $2); Then we can't do either planning time partition prune or init partition prune. Even though we have run-time partition pruning work at last, it is too late in some cases since we have to init all the plan nodes in advance. In my case, there are 10+ partitioned relation in one query and the execution time is short, so the init plan a lot of plan nodes cares a lot.
The attached patches fix this issue. It just get the "p.partkey = q.colx" case in root->eq_classes or rel->joinlist (outer join), and then check if there is some baserestrictinfo in another relation which can be used for partition pruning. To make the things easier, both partkey and colx must be Var expression in implementation. - v1-0001-Make-some-static-functions-as-extern-and-extend-C.patch Just some existing refactoring and extending ChangeVarNodes to be able to change var->attno. - v1-0002-Build-some-implied-pruning-quals-to-extend-the-us.patch Do the real job. Thought? -- Best Regards Andy Fan (https://www.aliyun.com/)
v1-0001-Make-some-static-functions-as-extern-and-extend-C.patch
Description: Binary data
v1-0002-Build-some-implied-pruning-quals-to-extend-the-us.patch
Description: Binary data
