On 3 March 2018 at 04:47, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Mar 2, 2018 at 6:21 AM, Amit Langote
> <Langote_Amit_f8@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