Hello Hackers,
The maximum size of the GID, used as a 2PC identifier is currently defined as 200 bytes (see src/backend/access/transam/twophase.c). The actual GID used by the applications though may be much smaller than that. So IMO instead of WAL logging the entire 200 bytes during PREPARE TRANSACTION, we should just WAL log strlen(gid) bytes.
The attached patch does that. The changes are limited to twophase.c and some simple crash recovery tests seem to be work ok. In terms of performance, a quick test shows marginal improvement in tps using the script that Stas Kelvich used for his work on speeding up twophase transactions. The only change I made is to keep the :scale unchanged because increasing the :scale in every iteration will result in only a handful updates (not sure why Stas had that in his original script)
\set naccounts 100000 * :scale
\setrandom from_aid 1 :naccounts
\setrandom to_aid 1 :naccounts
\setrandom delta 1 100
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance - :delta WHERE aid = :from_aid;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :to_aid;
PREPARE TRANSACTION ':client_id.:scale';
COMMIT PREPARED ':client_id.:scale';
The amount of WAL generated during a 60s run shows a decline of about 25% with default settings except full_page_writes which is turned off.
HEAD: 861 WAL bytes / transaction
PATCH: 670 WAL bytes / transaction
Actually, the above numbers probably include a lot of WAL generated because of HOT pruning and page defragmentation. If we just look at the WAL overhead caused by 2PC, the decline is somewhere close to 50%. I took numbers using simple 1PC for reference and to understand the overhead of 2PC.
HEAD (1PC): 382 bytes / transaction
Thanks,
