Hackers, When working in the read committed transaction isolation mode (default), we have the following sequence of actions when tuple_update() or tuple_delete() find concurrently updated tuple.
1. tuple_update()/tuple_delete() returns TM_Updated 2. tuple_lock() 3. Re-evaluate plan qual (recheck if we still need to update/delete and calculate the new tuple for update) 4. tuple_update()/tuple_delete() (this time should be successful, since we've previously locked the tuple). I wonder if we should merge steps 1 and 2. We could save some efforts already done during tuple_update()/tuple_delete() for locking the tuple. In heap table access method, we've to start tuple_lock() with the first tuple in the chain, but tuple_update()/tuple_delete() already visited it. For undo-based table access methods, tuple_update()/tuple_delete() should start from the last version, why don't place the tuple lock immediately once a concurrent update is detected. I think this patch should have some performance benefits on high concurrency. Also, the patch simplifies code in nodeModifyTable.c getting rid of the nested case. I also get rid of extra table_tuple_fetch_row_version() in ExecUpdate. Why re-fetch the old tuple, when it should be exactly the same tuple we've just locked. I'm going to check the performance impact. Thoughts and feedback are welcome. ------ Regards, Alexander Korotkov
0001-Lock-updated-tuples-in-tuple_update-and-tuple_del-v1.patch
Description: Binary data
