On 02/29/2016 08:45 AM, Pavan Deolasee wrote:
> 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
>
I can confirm the marginal speed up in tps due to the new WAL size.
The TWOPHASE_MAGIC constant should be changed, as the file header has
changed definition, right ?
Thanks for working on this !
Best regards, Jesper