On 5/27/22 02:11, Ranier Vilela wrote: > > ... > > Here the results with -T 60:
Might be a good idea to share your analysis / interpretation of the results, not just the raw data. After all, the change is being proposed by you, so do you think this shows the change is beneficial? > Linux Ubuntu 64 bits > shared_buffers = 128MB > > ./pgbench -M prepared -c $conns -j $conns -T 60 -S -n -U postgres > > pgbench (15beta1) > transaction type: <builtin: select only> > scaling factor: 1 > query mode: prepared > number of clients: 100 > number of threads: 100 > maximum number of tries: 1 > duration: 60 s > > conns tps head tps patched > > 1 17126.326108 17792.414234 > 10 82068.123383 82468.334836 > 50 73808.731404 74678.839428 > 80 73290.191713 73116.553986 > 90 67558.483043 68384.906949 > 100 65960.982801 66997.793777 > 200 62216.011998 62870.243385 > 300 62924.225658 62796.157548 > 400 62278.099704 63129.555135 > 500 63257.930870 62188.825044 > 600 61479.890611 61517.913967 > 700 61139.354053 61327.898847 > 800 60833.663791 61517.913967 > 900 61305.129642 61248.336593 > 1000 60990.918719 61041.670996 > These results look much saner, but IMHO it also does not show any clear benefit of the patch. Or are you still claiming there is a benefit? BTW it's generally a good idea to do multiple runs and then use the average and/or median. Results from a single may be quite noisy. > > Linux Ubuntu 64 bits > shared_buffers = 2048MB > > ./pgbench -M prepared -c $conns -j $conns -S -n -U postgres > > pgbench (15beta1) > transaction type: <builtin: select only> > scaling factor: 1 > query mode: prepared > number of clients: 100 > number of threads: 100 > maximum number of tries: 1 > number of transactions per client: 10 > > conns tps head tps patched > > 1 2918.004085 3211.303789 > 10 12262.415696 15540.015540 > 50 13656.724571 16701.182444 > 80 14338.202348 16628.559551 > 90 16597.510373 16835.016835 > 100 17706.775793 16607.433487 > 200 16877.067441 16426.969799 > 300 16942.260775 16319.780662 > 400 16794.514911 16155.023607 > 500 16598.502151 16051.106724 > 600 16717.935001 16007.171213 > 700 16651.204834 16004.353184 > 800 16467.546583 16834.591719 > 900 16588.241149 16693.902459 > 1000 16564.985265 16936.952195 > I think we've agreed these results are useless. > > Linux Ubuntu 64 bits > shared_buffers = 2048MB > > ./pgbench -M prepared -c $conns -j $conns -T 60 -S -n -U postgres > > pgbench (15beta1) > transaction type: <builtin: select only> > scaling factor: 1 > query mode: prepared > number of clients: 100 > number of threads: 100 > maximum number of tries: 1 > duration: 60 s > > conns tps head tps patched > > 1 17174.265804 17792.414234 > 10 82365.634750 82468.334836 > 50 74593.714180 74678.839428 > 80 69219.756038 73116.553986 > 90 67419.574189 68384.906949 > 100 66613.771701 66997.793777 > 200 61739.784830 62870.243385 > 300 62109.691298 62796.157548 > 400 61630.822446 63129.555135 > 500 61711.019964 62755.190389 > 600 60620.010181 61517.913967 > 700 60303.317736 61688.044232 > 800 60451.113573 61076.666572 > 900 60017.327157 61256.290037 > 1000 60088.823434 60986.799312 > I have no idea why shared buffers 2GB would be interesting. The proposed change was related to procarray, not shared buffers. And scale 1 is ~15MB of data, so it fits into 128MB just fine. Also, the first ~10 results for "patched" case match results for 128MB shared buffers. That seems very unlikely to happen by chance, so this seems rather suspicious. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
