-
Marc Alff authored
PERFORMANCE_SCHEMA.THREADS.PROCESSLIST_STATE Prior to this fix, the server code executed the following calls to the performance schema for each change in processlist state: - pfs_set_thread_state_v1() - pfs_start_stage_v1() pfs_set_thread_state_v1 sets the THREADS.PROCESSLIST_STATE column with a string. To protect the string pointer, a PFS_lock is used, which causes two atomic operations per call. pfs_start_stage_v1 sets the current thread stage key. The problem is that using atomics causes overhead, and that setting both a state string and a stage key is redundant, since the thread state string is in fact coming from the stage. This fix simplify the instrumentation: - the call to pfs_set_thread_state_v1() is removed - the implementation of column THREADS.PROCESSLIST_STATE now extract the state string from the stage provided by pfs_start_stage_v1.
Marc Alff authoredPERFORMANCE_SCHEMA.THREADS.PROCESSLIST_STATE Prior to this fix, the server code executed the following calls to the performance schema for each change in processlist state: - pfs_set_thread_state_v1() - pfs_start_stage_v1() pfs_set_thread_state_v1 sets the THREADS.PROCESSLIST_STATE column with a string. To protect the string pointer, a PFS_lock is used, which causes two atomic operations per call. pfs_start_stage_v1 sets the current thread stage key. The problem is that using atomics causes overhead, and that setting both a state string and a stage key is redundant, since the thread state string is in fact coming from the stage. This fix simplify the instrumentation: - the call to pfs_set_thread_state_v1() is removed - the implementation of column THREADS.PROCESSLIST_STATE now extract the state string from the stage provided by pfs_start_stage_v1.
Loading