Dear hackers,
> I understand your concern and appreciate the feedback. I've made some
> adjustments to the patch by directly placing the code to adjust the commit
> timestamp within the spinlock, aiming to keep it as efficient as possible. The
> changes have resulted in just a few extra lines. Would this approach be
> acceptable to you ?
>
> Additionally, we're also doing performance tests for it and will share the
> results once they're available.
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
Here is a result.
Each run had 60s periods and median of 5 runs were chosen.
### Single-tuple insertion
# of clients HEAD V2 diff
1 5602.828793 5593.991167 0.158%
2 10547.04503 10615.55583 -0.650%
4 15967.80926 15651.12383 1.983%
8 31213.14796 30584.75382 2.013%
16 60321.34215 59998.0144 0.536%
32 111108.2883 110615.9216 0.443%
64 171860.0186 171359.8172 0.291%
### Transactional message
# of clients HEAD V2 diff
1 5714.611827 5648.9299 1.149%
2 10651.26476 10677.2745 -0.244%
4 16137.30248 15984.11671 0.949%
8 31220.16833 30772.53673 1.434%
16 60364.22808 59866.92579 0.824%
32 111887.1129 111406.4923 0.430%
64 172136.76 171347.5658 0.458%
Actually the standard deviation of each runs was almost the same (0-2%), so we could
conclude that there were no significant difference.
## Appendix - measurement environments
- Used machine has 755GB memory and 120 cores (Intel(R) Xeon(R) CPU E7-4890).
- RHEL 7.9 is running on the machine
- HEAD pointed the commit 41b98ddb7 when tested.
- Only `--prefix` was specified for when configured.
- Changed parameters from the default were:
```
autovacuum = false
checkpoint_timeout = 1h
shared_buffers = '30GB'
max_wal_size = 20GB
min_wal_size = 10GB
```
Best regards,
Hayato Kuroda
FUJITSU LIMITED
