On Fri, Mar 16, 2018 at 5:13 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
> (2018/03/16 19:43), Pavan Deolasee wrote: > >> On Fri, Mar 2, 2018 at 9:06 PM, Alvaro Herrera <alvhe...@2ndquadrant.com >> <mailto:alvhe...@2ndquadrant.com>> wrote: >> > > @@ -106,6 +120,9 @@ typedef struct PartitionTupleRouting >> int num_subplan_partition_offsets; >> TupleTableSlot *partition_tuple_slot; >> TupleTableSlot *root_tuple_slot; >> + List **partition_arbiter_indexes; >> + TupleTableSlot **partition_conflproj_slots; >> + TupleTableSlot **partition_existing_slots; >> } PartitionTupleRouting; >> > > I am curious why you decided to add these members to >> PartitionTupleRouting structure. Wouldn't ResultRelationInfo be a better >> place to track these or is there some rule that we follow? >> > > I just started reviewing the patch, so maybe I'm missing something, but I > think it would be a good idea to have these in that structure, not in > ResultRelInfo, because these would be required only for partitions chosen > via tuple routing. > Hmm, yeah, probably you're right. The reason I got confused is because the patch uses ri_onConflictSetProj/ri_onConflictSetWhere to store the converted projection info/where clause for a given partition in its ResultRelationInfo. So I was wondering if we can move mt_arbiterindexes, mt_existing and mt_conflproj to ResultRelInfo and then just use that per-partition structures too. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
