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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers