Dear hackers, Based on the requirement, I have profiled the performance test. It showed bottlenecks are in small-data case are mainly two - starting a server and waiting until the recovery is done.
# Tested source code V7 patch set was applied atop HEAD(0eb23285). No configure options were specified when it was built. # Tested workload I focused on only 100MB/1GB cases because bigger ones have already had good performance. (Number of inserted tuples were same as previous tests) I used bash script instead of tap test framework. See attached. Executed SQLs and operations were almost the same. As you can see, I tested only one-db case. Results may be changed if the number of databases were changed. # Measurement Some debug logs which output current time were added (please see diff file). I picked up some events and done at before/after them. Below bullets showed the measured ones: * Starting a server * Stopping a server * Creating replication slots * Creating publications * Waiting until the recovery ended * Creating subscriptions # Result Below table shows the elapsed time for these events. Raw data is also available by the attached excel file. |Event category |100MB case [sec]|1GB [sec]| |Starting a server |1.414 |1.417 | |Stoping a server |0.506 |0.506 | |Creating replication slots |0.005 |0.007 | |Creating publications |0.001 |0.002 | |Waiting until the recovery ended|1.603 |14.529 | |Creating subscriptions |0.012 |0.012 | |Total |3.541 |16.473 | |actual time |4.37 |17.271 | As you can see, starting servers and waiting seem slow. We cannot omit these, but setting smaller shared_buffers will reduce the start time. One approach is to overwrite the GUC to smaller value, but I think we cannot determine the appropriate value. Best Regards, Hayato Kuroda FUJITSU LIMITED
run.sh
Description: run.sh
perf_result.xlsx
Description: perf_result.xlsx
add_debug_log.diff
Description: add_debug_log.diff