Various tests show that the controlled advancement of write_lsn in __log_release results in a lot of time wasted in yield or cond_wait and scheduling issues. With the default of running logging in-memory, application threads should not have to wait for the LSN to advance to continue.

My initial thoughts for this are to have a worker thread that scans through the slot pool looking for slots that can advance write_lsn and are done writing. We would add a new state that would be set on the slot in log_release and the worker thread would see it and could advance write_lsn.

Various things to think about:

• Threads that need to sync anyway must still wait for the LSN to advance so the existing code likely remains in a conditional code path.
• The thread calling log_release frees the slot when done. We'll need a new flag, or return value or something to only do that conditionally when the log_release thread does not hand off the slot. Otherwise the worker thread will free the slot when it does its work.
• Consideration for the worker thread back-off yield mechanism to be somewhat sophisticated. It is important that the write_lsn be advanced in a timely manner, but we don't want to spin when there are not many writes.
• Need a new slot state that will indicate to the worker thread this slot should be processed by it.
• Careful consideration for all the various log sync settings and making sure threads are properly waiting (or not) for all the different settings.