Hi, On 2022-05-27 03:30:46 +0200, Tomas Vondra wrote: > On 5/27/22 02:11, Ranier Vilela wrote: > > ./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?
They don't look all that sane to me - isn't that way lower than one would expect? Restricting both client and server to the same four cores, a thermically challenged older laptop I have around I get 150k tps at both 10 and 100 clients. Either way, I'd not expect to see any GetSnapshotData() scalability effects to show up on an "Intel® Core™ i5-8250U CPU Quad Core" - there's just not enough concurrency. The correct pieces of these changes seem very unlikely to affect GetSnapshotData() performance meaningfully. To improve something like GetSnapshotData() you first have to come up with a workload that shows it being a meaningful part of a profile. Unless it is, performance differences are going to just be due to various forms of noise. Greetings, Andres Freund
