On 3 March 2018 at 04:47, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Mar 2, 2018 at 6:21 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> Looking at the rough interface sketch in your message, it seems that the >> product of whatever steps we end up grouping into phase 1 should be >> something that can be put into a Node tree (PartitionPruneContext?), >> because we may need to attach it to the plan if some of the needed values >> will only be made available during execution. > > Right. You might also end up with two representations: a > Node-tree-style representation that contains all of the information we > need, and another, faster form into which it gets converted before > use.
hmm, I thought Amit typed PartitionPruneContext instead of PartitionClauseInfo by mistake here. PartitionPruneContext can't be a node type. The run-time pruning patch needs to set the PlanState in this context so that the code can lookup the Param values when being called from the executor. You can't make PlanState a node type too! Perhaps you can make some primnode type to store all the stuff from RelOptInfo that's currently being stored in PartitionPruneContext. That could go along with the plan to save the executor having to look that stuff up. We can then make that Node type a field in the PartitionPruneContext. You could even reuse that Node from when it would first get generated during query planning pruning and keep it around for use to pass to the executor for run-time pruning, but you'd probably need to stuff it somewhere like the partition's RelOptInfo so it could be reused again later. Unsure if that's worth the trouble or not. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services