Re: Commit Timestamp and LSN Inversion issue
От | Andres Freund |
---|---|
Тема | Re: Commit Timestamp and LSN Inversion issue |
Дата | |
Msg-id | 43vrkfqyv72ofuxhltur35twwcxiyujqrcfu3b26yzy4o5eyg3@g4fxomgmnqgk обсуждение исходный текст |
Ответ на | RE: Commit Timestamp and LSN Inversion issue ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
RE: Commit Timestamp and LSN Inversion issue
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: