On Tue, Dec 21, 2021 at 5:58 AM Euler Taveira <eu...@eulerto.com> wrote: > > I reviewed 0003. It uses TupleTableSlot instead of HeapTuple. I probably > missed > the explanation but it requires more changes (logicalrep_write_tuple and 3 new > entries into RelationSyncEntry). I replaced this patch with a slightly > different one (0005 in this patch set) that uses HeapTuple instead. I didn't > only simple tests and it requires tests. I noticed that this patch does not > include a test to cover the case where TOASTed values are not included in the > new tuple. We should probably add one.
The reason I changed the code to use virtualtuple slots is to reduce tuple deforming overhead. Dilip raised this very valid comment in [1]: On Tue, Sep 21, 2021 at 4:29 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote: > >In pgoutput_row_filter_update(), first, we are deforming the tuple in >local datum, then modifying the tuple, and then reforming the tuple. >I think we can surely do better here. Currently, you are reforming >the tuple so that you can store it in the scan slot by calling >ExecStoreHeapTuple which will be used for expression evaluation. >Instead of that what you need to do is to deform the tuple using >tts_values of the scan slot and later call ExecStoreVirtualTuple(), so >advantages are 1) you don't need to reform the tuple 2) the expression >evaluation machinery doesn't need to deform again for fetching the >value of the attribute, instead it can directly get from the value >from the virtual tuple. Storing the old tuple/new tuple in a slot and re-using the slot avoids the overhead of continuous deforming of tuple at multiple levels in the code. regards, Ajin Cherian [1] - https://www.postgresql.org/message-id/CAFiTN-vwBjy+eR+iodkO5UVN5cPv_xx1=s8ehzgcrjza+az...@mail.gmail.com
