R
Richard Banville
Guest
#1 - This is an oversight that can be cleaned up. I'll have a bug filed. Realize that it is "functionally correct" but can be improved to help with performance. #2 - The difference is that the USR and SCH latches queue to acquire the latch. The TXQ latch does not queue to acquire the latch but a conflict in acquiring the TXE lock will queue waiting for the lock. This mechanism is similar to how the BUF latch and the buffer lock work together. #3 - We continue to work on opening every flood gate possible. As we make the higher level latches more concurrent, it pushes the next bottleneck lower in the stack. Just because there is a contentious bottleneck at a lower level does not mean however that making higher level processing more concurrent should not be done, it just means that the end user's over all operation is not complety concurrent yet. For example, the plan with the LKF latch was to remove it altogether and make acquiring a free lock table entry a latch free atomic operation. I had prototyped this when I did the latch concurrency improvements in 10.1C. Even though it is latch free, there is still contention at the machine level for the atomic swap so the minor performance improvement seen at that time did not warrent the risk. Without multiple free chains, the overall operation will not be 100% concurrent - its just that you as the end user will not have the information to identify it. I agree, this is something we should revisit. As always, there is more work to do to improve the concurrency of shared resources for performacne reasons and we continue to work in this are. Thanks for your insights.
Continue reading...
Continue reading...