On Wed, Aug 30, 2017 at 6:08 AM, Amit Khandekar <amitdkhan.pg@gmail.com> wrote:
> On 25 August 2017 at 23:58, Robert Haas <robertmhaas@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