On 2017/08/07 14:37, Amit Khandekar wrote: > On 4 August 2017 at 22:55, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
