On Thu, Jul 9, 2020 at 1:53 AM Soumyadeep Chakraborty
<soumyadeep2007@gmail.com> wrote:
> On Tue, Jul 7, 2020 at 7:17 PM Amit Langote <amitlangote09@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