On Mon, Mar 7, 2022 at 12:04 PM Álvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> On Mon, Mar 7, 2022, at 4:59 PM, Álvaro Herrera wrote: > > I attach v13 here. This version includes a 0002 that's does the split of > nodeModifyTable.c routines, then 0003 implements MERGE on top of that. > 0001 is as before. > > > In 0002, I've opted to have two separate structs. One is the > ModifyTableContext, as before, but I've removed 'tupleid' and 'oldtuple' > (the specification of the tuple to delete/update) because it makes > ExecCrossPartitionUpdate cleaner if we pass them separately. The second > struct is UpdateContext, which is used inside ExecUpdate as output data > from its subroutines. This is also for the benefit of cross-partition > updates. > > I'm pretty happy with how this turned out; even without considering MERGE, > it seems to me that ExecUpdate benefits from being shorter. > Hi, For v13-0003-MERGE-SQL-Command-following-SQL-2016.patch : + * Reset per-tuple memory context to free any expression evaluation + * storage allocated in the previous cycle. + */ + ResetExprContext(econtext); Why is the memory cleanup done in the next cycle ? Can the cleanup be done at the end of the current cycle ? + * XXX Should this explain why MERGE has the same logic as UPDATE? I think explanation should be given. Cheers
