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
