Re: WAL log only necessary part of 2PC GID
От | Jesper Pedersen |
---|---|
Тема | Re: WAL log only necessary part of 2PC GID |
Дата | |
Msg-id | 56D9ADDA.3030502@redhat.com обсуждение исходный текст |
Ответ на | WAL log only necessary part of 2PC GID (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Ответы |
Re: WAL log only necessary part of 2PC GID
|
Список | 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
В списке pgsql-hackers по дате отправления: