On 2017/07/03 18:54, Amit Langote wrote:
> On 2017/07/02 20:10, Robert Haas wrote:
>> But that seems like it wouldn't be too hard to fix: let's have
>> expand_inherited_rtentry() expand the partitioned table in the same
>> order that will be used by ExecSetupPartitionTupleRouting().
That's really what I wanted when updating the patch for tuple-routing to
foreign partitions. (I don't understand the issue discussed here, though.)
>> That
>> seems pretty easy to do - just have expand_inherited_rtentry() notice
>> that it's got a partitioned table and call
>> RelationGetPartitionDispatchInfo() instead of find_all_inheritors() to
>> produce the list of OIDs.
Seems like a good idea.
> Interesting idea.
>
> If we are going to do this, I think we may need to modify
> RelationGetPartitionDispatchInfo() a bit or invent an alternative that
> does not do as much work. Currently, it assumes that it's only ever
> called by ExecSetupPartitionTupleRouting() and hence also generates
> PartitionDispatchInfo objects for partitioned child tables. We don't need
> that if called from within the planner.
>
> Actually, it seems that RelationGetPartitionDispatchInfo() is too coupled
> with its usage within the executor, because there is this comment:
>
> /*
> * We keep the partitioned ones open until we're done using the
> * information being collected here (for example, see
> * ExecEndModifyTable).
> */
Yeah, we need some refactoring work. Is anyone working on that?
Best regards,
Etsuro Fujita