On Wed, Aug 30, 2017 at 9:42 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Aug 30, 2017 at 6:08 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> On 25 August 2017 at 23:58, Robert Haas <robertmh...@gmail.com> wrote: >>> That just leaves indexes. In a world where keystate, tupslot, and >>> tupmap are removed from the PartitionDispatchData, you must need >>> indexes or there would be no point in constructing a >>> PartitionDispatchData object in the first place; any application that >>> needs neither indexes nor the executor-specific stuff could just use >>> the Relation directly. >> >> But there is expand_inherited_rtentry() which neither requires indexes >> nor any executor stuff, but still requires to call >> RelationGetPartitionDispatchInfo(), and so these indexes get built >> unnecessarily. > > True, but the reason why expand_inherited_rtentry() needs to call > RelationGetPartitionDispatchInfo() is to get back the leaf partition > OIDs in bound order. If we're using > RelationGetPartitionDispatchInfo() to get the leaf partition OIDs into > bound order, we've got to run the loop that builds leaf_part_oids, and > the same loop constructs indexes. So I don't think we're doing much > redundant work there. > > Now, if we made it the job of expand_inherited_rtentry() to loop over > the PartitionDesc, then it really wouldn't need to call > RelationGetPartitionDispatchInfo at all. Maybe that's actually a > better plan anyway, because as Ashutosh points out, we don't want the > partitioned children to show up before the unpartitioned children in > the resulting ordering. >
+1. I think we should just pull out the OIDs from partition descriptor. -- Best Wishes, Ashutosh Bapat 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
