Pavan Deolasee wrote: > 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.
I wonder if the proposed structure is good actually. Some notes as I go along. 1. ModifyTableState->mt_arbiterindexes is just a copy of ModifyTable->arbiterIndexes. So why do we need it? For an unpartitioned relation we can just use ModifyTableState.ps->arbiterIndexes. Now, for each partition we need to map these indexes onto the partition indexes. Not sure where to put these; I'm tempted to say ResultRelInfo is the place. Maybe the list should always be in ResultRelInfo instead of the state/plan node? Not sure. 2. We don't need mt_existing to be per-relation; a single tuple slot can do for all partitions; we just need to ExecSlotSetDescriptor to the partition's descriptor whenever the slot is going to be used. (This means the slot no longer has a fixed tupdesc. That seems OK). 3. ModifyTableState->mt_conflproj is more or less the same thing; the same TTS can be reused by all the different projections, as long as we set the descriptor before projecting. So we don't need PartitionTupleRouting->partition_conflproj_slots, but we do need a descriptor to be used when needed. Let's say PartitionTupleRouting->partition_confl_tupdesc I'll experiment with these ideas and see where that leads me. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services