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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers