Hey Amit, On Tue, Jul 7, 2020 at 7:17 PM Amit Langote <[email protected]> wrote: > Ah, I see. You might've noticed that ExecInsert() only ever sees leaf > partitions, because tuple routing would've switched the result > relation to a leaf partition by the time we are in ExecInsert(). So, > table_tuple_insert() always refers to a leaf partition's AM. Not > sure if you've also noticed but each leaf partition gets to own a slot > (PartitionRoutingInfo.pi_PartitionTupleSlot), but currently it is only > used if the leaf partition attribute numbers are not the same as the > root partitioned table. How about we also use it if the leaf > partition AM's table_slot_callbacks() differs from the root > partitioned table's slot's tts_ops? That would be the case, for > example, if the leaf partition is of Zedstore AM. In the more common > cases where all leaf partitions are of heap AM, this would mean the > original slot would be used as is, that is, if we accept hard-coding > table_slot_callbacks() to return a "heap" slot for partitioned tables > as I suggest.
Even then, we will still need to fill in the system columns explicitly as pi_PartitionTupleSlot will not be filled with system columns after it comes back out of table_tuple_insert() if we have a non-heap AM. Regards, Soumyadeep (VMware)
