On Wed, Aug 30, 2017 at 9:42 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
>
+1. I think we should just pull out the OIDs from partition descriptor.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company