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