On 4 July 2017 at 14:48, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 4 July 2017 at 14:38, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> On 2017/07/04 17:25, Etsuro Fujita wrote: >>> On 2017/07/03 18:54, Amit Langote wrote: >>>> On 2017/07/02 20:10, Robert Haas wrote: >>>>> 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? >> >> I would like to take a shot at that if someone else hasn't already cooked >> up a patch. Working on making RelationGetPartitionDispatchInfo() a >> routine callable from both within the planner and the executor should be a >> worthwhile effort. > > What I am currently working on is to see if we can call > find_all_inheritors() or find_inheritance_children() instead of > generating the leaf_part_oids using APPEND_REL_PARTITION_OIDS(). > Possibly we don't have to refactor it completely. > find_inheritance_children() needs to return the oids in canonical > order. So in find_inheritance_children () need to re-use part of > RelationBuildPartitionDesc() where it generates those oids in that > order. I am checking this part, and am going to come up with an > approach based on findings.
The other approach is to make canonical ordering only in find_all_inheritors() by replacing call to find_inheritance_children() with the refactored/modified RelationGetPartitionDispatchInfo(). But that would mean that the callers of find_inheritance_children() would have one ordering, while the callers of find_all_inheritors() would have a different ordering; that brings up chances of deadlocks. That's why I think, we need to think about modifying the common function find_inheritance_children(), so that we would be consistent with the ordering. And then use find_inheritance_children() or find_all_inheritors() in RelationGetPartitionDispatchInfo(). So yes, there would be some modifications to RelationGetPartitionDispatchInfo(). > > Also, need to investigate whether *always* sorting the oids in > canonical order is going to be much expensive than the current sorting > using oids. But I guess it won't be that expensive. > > > -- > Thanks, > -Amit Khandekar > EnterpriseDB Corporation > The Postgres Database Company -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
