> On 01/12/2020, 16:59, "Alexander Korotkov" <aekorot...@gmail.com> wrote: > On Tue, Dec 1, 2020 at 1:10 PM Amit Khandekar <amitdkhan...@gmail.com> wrote: > > FWIW, here is an earlier discussion on the same (also added the > > proposal author here) :
Thanks for looping me in! > > > > > https://www.postgresql.org/message-id/flat/099F69EE-51D3-4214-934A-1F28C0A1A7A7%40amazon.com > > > Thank you for pointing! I wonder why the effect of LSE on Graviton2 > observed by Tsahi Zidenberg is so modest. It's probably because he > runs the tests with a low number of clients. There are multiple possible reasons why I saw a smaller effect of LSE, but I think an important one was that I used a 32-core instance rather than a 64-core one. The reason I did so, was that 32-cores gave me better absolute results than 64 cores, and I didn't want to feel like I could misguide anyone. The 64-core instance results is a good example for the benefit of LSE. LSE becomes most important in edges, and with adversarial workloads. If multiple CPUs try to acquire a lock simultaneously - LSE ensures one CPU will indeed get the lock (with just one transaction), while LDRX/STRX could have multiple CPUS looping and no-one acquiring a lock. This is why I believe just looking at "reasonable" benchmarks misses out on effects real customers will run into. Happy to see another arm-optimization thread so quickly :) Thank you! Tsahi.
