agorrod I'm opening this issue up to discuss either the user reconfiguring, or maybe later, the system automatically choosing to stop or start additional LSM worker threads. The functionality is very similar to reconfiguring the number of async threads. I think with a small change to the way the LSM manager gets initialized, we could use very similar code.

I think changing the number of worker threads would be fairly easy if the session array was statically allocated in the structure to the maximum (20) allowed. That is what async does. Then it is very easy to start more threads - you just use more session slots and the existing threads don't know any different. Or to stop some threads, you start at the end of the session array and stop as many as needed, so that all running sessions are always packed at the beginning of the array.

For async, I needed a session flag in addition to the connection server run flag so that an individual session's flags could be set to trigger that thread to stop. You can look in __wt_async_reconfig cases 5 and 6 for the code.