Hi,
I did some performance test for the master branch patch (based on v6 patch) to
see if the bsearch() added by this patch will cause any overhead.
I tested them three times and took the average.
The results are as follows, and attach the bar chart.
case 1
---------
No catalog modifying transaction.
Decode 800k pgbench transactions. (8 clients, 100k transactions per client)
master 7.5417
patched 7.4107
case 2
---------
There's one catalog modifying transaction.
Decode 100k/500k/1M transactions.
100k 500k 1M
master 0.0576 0.1491 0.4346
patched 0.0586 0.1500 0.4344
case 3
---------
There are 64 catalog modifying transactions.
Decode 100k/500k/1M transactions.
100k 500k 1M
master 0.0600 0.1666 0.4876
patched 0.0620 0.1653 0.4795
(Because the result of case 3 shows that there is a overhead of about 3% in the
case decoding 100k transactions with 64 catalog modifying transactions, I
tested the next run of 100k xacts with or without catalog modifying
transactions, to see if it affects subsequent decoding.)
case 4.1
---------
After the test steps in case 3 (64 catalog modifying transactions, decode 100k
transactions), run 100k xacts and then decode.
master 0.3699
patched 0.3701
case 4.2
---------
After the test steps in case 3 (64 catalog modifying transactions, decode 100k
transactions), run 64 DDLs(without checkpoint) and 100k xacts, then decode.
master 0.3687
patched 0.3696
Summary of the tests:
After applying this patch, there is a overhead of about 3% in the case decoding
100k transactions with 64 catalog modifying transactions. This is an extreme
case, so maybe it's okay. And case 4.1 and case 4.2 shows that the patch has no
effect on subsequent decoding. In other cases, there are no significant
differences.
For your information, here are the parameters specified in postgresql.conf in
the test.
shared_buffers = 8GB
checkpoint_timeout = 30min
max_wal_size = 20GB
min_wal_size = 10GB
autovacuum = off
Regards,
Shi yu
