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