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
