On 02/29/2016 08:45 AM, Pavan Deolasee wrote:
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
UPDATE pgbench_accounts SET abalance = abalance - :delta WHERE aid =
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE 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
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 !
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: