Hi, On 2024-06-05 21:59:42 -0400, Robert Haas wrote: > On Wed, Jun 5, 2024 at 9:50 PM Andres Freund <and...@anarazel.de> wrote: > > Depending on the architecture / ABI / compiler options it's often not > > meaningfully more expensive to access a thread local variable than a > > "normal" > > variable. > > > > I think these days it's e.g. more expensive on x86-64 windows, but not > > linux. On arm the overhead of TLS is more noticeable, across platforms, > > afaict. > > I mean, to me, this still sounds like we want multithreading to be a > build-time option.
Maybe. I think shipping a mode where users can fairly simply toggle between threaded and process mode will allow us to get this stable a *lot* quicker than if we distribute two builds. Most users don't build from source, distros will have to pick the mode. If they don't choose threaded mode, we'll not find problems. If they do choose threaded mode, we can't ask users to switch to a process based mode to check if the problem is related. We have been talking in a bunch of threads about having a mode where the main postgres binary chooses a build optimized for the current architecture, to be able to use SIMD instructions without a runtime check/dispatch. I guess we could add threadedness to such a matrix... Greetings, Andres Freund