Re: WAL log only necessary part of 2PC GID

From: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAL log only necessary part of 2PC GID
Date: 2016-03-04 15:46:34
Message-ID: 56D9ADDA.3030502@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-03-04 15:46:54 Re: postgres_fdw vs. force_parallel_mode on ppc
Previous Message Alexander Korotkov 2016-03-04 15:38:44 Re: pg_resetxlog reference page reorganization