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.