pgsql: Optimize updating a row that's locked by same xid

Optimize updating a row that's locked by same xid

Updating or locking a row that was already locked by the same
transaction under the same Xid caused a MultiXact to be created; but
this is unnecessary, because there's no usefulness in being able to
differentiate two locks by the same transaction. In particular, if a
transaction executed SELECT FOR UPDATE followed by an UPDATE that didn't
modify columns of the key, we would dutifully represent the resulting
combination as a multixact -- even though a single key-update is
sufficient.

Optimize the case so that only the strongest of both locks/updates is
represented in Xmax. This can save some Xmax's from becoming
MultiXacts, which can be a significant optimization.

This missed optimization opportunity was spotted by Andres Freund while
investigating a bug reported by Oliver Seemann in message
CANCipfpfzoYnOz5jj=UZ70_R=CwDHv36dqWSpwsi27vpm1z5sA(at)mail(dot)gmail(dot)com
and also directly as a performance regression reported by Dong Ye in
message
d54b8387(dot)000012d8(dot)00000010(at)YED-DEVD1(dot)vmware(dot)com
Reportedly, this patch fixes the performance regression.

Since the missing optimization was reported as a significant performance
regression from 9.2, backpatch to 9.3.

Andres Freund, tweaked by Álvaro Herrera

Branch
------
REL9_3_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/85d3b3c3ac16ea7d8f7b513d8ac7bc2f88bb988f

Modified Files
--------------
src/backend/access/heap/heapam.c | 70 +++++++++++++++++++++-----------------
1 file changed, 39 insertions(+), 31 deletions(-)