On 2017/08/07 14:37, Amit Khandekar wrote:
> On 4 August 2017 at 22:55, Robert Haas <robertmhaas@gmail.com> wrote:
>> P.S. While I haven't reviewed 0002 in detail, I think the concept of
>> minimizing what needs to be built in RelationGetPartitionDispatchInfo
>> is a very good idea.
>
> True. I also think, RelationGetPartitionDispatchInfo () should be
> called while preparing the ModifyTable plan; the PartitionDispatch
> data structure returned by RelationGetPartitionDispatchInfo() should
> be stored in that plan, and then the execution-time fields in
> PartitionDispatch would be populated in ExecInitModifyTable().
I'm not sure if we could ever store the PartitionDispatch structure itself
in the plan.
Planner would build and use it to put the leaf partition sub-plans in the
canonical order in the resulting plan (Append, ModifyTable, etc.).
Executor will have to rebuild the PartitionDispatch info again if and when
it needs the same (for example, in ExecSetupPartitionTupleRouting for
insert or update tuple routing).
The refactoring patch that I've proposed (0002) makes PartitionDispatch
structure itself contain a lot less information/state than it currently
does. So RelationGetPartitionDispatchInfo's job per the revised patch is
to reveal the partition tree structure and the information of each
partitioned table that the tree contains. The original design whereby it
builds and puts into PartitionDispatchData thing like partition key
execution state (ExprState), TupleTableSlot, TupleConversionMap seems
wrong to me in retrospect and we should somehow revise it. Those things I
mentioned are only needed for tuple-routing, so they should be built and
managed by the executor, not partition.c. Any feedback on the proposed
patch is welcome. :)
Thanks,
Amit