On Thu, Jul 9, 2020 at 1:53 AM Soumyadeep Chakraborty <soumyadeep2...@gmail.com> wrote: > On Tue, Jul 7, 2020 at 7:17 PM Amit Langote <amitlangot...@gmail.com> 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.
Well, I was hoping that table_tuple_insert() would fill that info, but you did say upthread that table AMs are not exactly expected to do so, so maybe you have a point. By the way, what happens today if you do INSERT INTO a_zedstore_table ... RETURNING xmin? Do you get an error "xmin is unrecognized" or some such in slot_getsysattr() when trying to project the RETURNING list? -- Amit Langote EnterpriseDB: http://www.enterprisedb.com
