> On 2017-09-21 15:51:54 -0500, Jim Van Fleet wrote: > > Not to beat on a dead horse, or anything, but this fix was frowned upon > > because in one environment (one socket) it was 6% down and over 15% up in > > the right environment (two sockets). > > > So, why not add a configuration parameter which specifies the number of > > parts? Default is 1 which would be "exactly" the same as no parts and > > hence no degradation in the single socket environment -- and with 2, you > > get some positive performance. > > Several reasons: > > - You'd either add a bunch of branches into a performance critical > parts, or you'd add a compile time flag, which most people would be > unable to toggle. I agree, no compile time flags -- but no extra testing in the main path -- gets set at init and not changed from there. > - It'd be something hard to tune, because even on multi-socket machines > it'll be highly load dependant. E.g. workloads that largely are > bottlenecked in a single backend / few backends will probably regress > as well. Workloads are hard to tune -- with the default, you have what you have today. If you "know" the issue is ProcArrayLock, then you have an alternative to try. > > FWIW, you started a new thread with this message, that doesn't seem > helpful?