Feedback-ID: id4a34324:Fastmail
Date: Tue, 12 Nov 2024 09:06:23 -0500
From: Andres Freund <andres@anarazel.de>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, 
	Amit Kapila <amit.kapila16@gmail.com>, Aleksander Alekseev <aleksander@timescale.com>, 
	shveta malik <shveta.malik@gmail.com>, "tomas@vondra.me" <tomas@vondra.me>, Jan Wieck <jan@wi3ck.info>, 
	"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Subject: Re: Commit Timestamp and LSN Inversion issue
Message-ID: <43vrkfqyv72ofuxhltur35twwcxiyujqrcfu3b26yzy4o5eyg3@g4fxomgmnqgk>
References: <CAJpy0uBxEJnabEp3JS=n9X19Vx2ZK3k5AR7N0h-cSMtOwYV3fA@mail.gmail.com>
 <CAJ7c6TNZY3idBDoGOaoS_fF6vJuBMjnDhZC4i5V0J58s2SJ3AA@mail.gmail.com>
 <CAA4eK1LOmtMpmJAxsmN0yXJb-Q9vi6KThDYXdpVGL_WZW5ZgvQ@mail.gmail.com>
 <CAJ7c6TOcQPcydC7HW=xPEDN6_Ec7iSTP9j=1VTAeG=haguOQHw@mail.gmail.com>
 <CAA4eK1KhAxe6=VTxa6xEbc22_VVBLsVuvRH8Wxws8i50gH=eqw@mail.gmail.com>
 <9f7f4def-7ea8-4ad3-83e7-a8cc9d18c58a@wi3ck.info>
 <gkbrjxwyjbqckjbrkep3uy2mvrcq2mrfzprfmegbeiqxidtmbu@3cgs5iocjykk>
 <OS0PR01MB57162A227EC357482FEB4470945D2@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <TYAPR01MB569222C1312E7A6C3C63539DF5582@TYAPR01MB5692.jpnprd01.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <TYAPR01MB569222C1312E7A6C3C63539DF5582@TYAPR01MB5692.jpnprd01.prod.outlook.com>
Archived-At: <https://www.postgresql.org/message-id/43vrkfqyv72ofuxhltur35twwcxiyujqrcfu3b26yzy4o5eyg3%40g4fxomgmnqgk>
Precedence: bulk

Hi,

On 2024-11-11 09:49:19 +0000, Hayato Kuroda (Fujitsu) wrote:
> I've done performance tests compared with master vs. v2 patch.
> It showed that for small transactions cases, the performance difference was 0-2%,
> which was almost the same of the run-by-run variation.
> 
> We may completely change the approach based on the recent discussion,
> but let me share it once.
> 
> ## Executed workload
> 
> Very small transactions with many clients were executed and results between master
> and patched were compared. Two workloads were executed and compared:
> 
> - Insert single tuple to the table which does not have indices:
> ```
> BEGIN;
> INSERT INTO foo VALUES (1);
> COMMIT;
> ```
> 
> - Emit a transactional logical replication message:
> ```
> BEGIN;
> SELECT pg_logical_emit_message(true, 'pgbench', 'benchmarking', false);
> COMMIT;
> ```
> 
> ## Results

This is not a useful measurement for overhead introduced in
ReserveXLogInsertLocation(). What you're measuring here is the number of
commits/second, not the WAL insertion rate. The number of commits/second is
largely determined by your disk's write latency, the batching of WAL flushes
and things like the SLRU code.

To measure the effect of changes to ReserveXLogInsertLocation() use something
like this as a pgbench script:
SELECT pg_logical_emit_message(false, \:client_id::text, '1'), generate_series(1, 10000) OFFSET 10000;

Greetings,

Andres Freund