WL#9764: PERFORMANCE_SCHEMA SERVICE FOR COMPONENTS
Affects: Server-8.0 — Status: Complete — Priority: Medium
Expose the existing performance schema interface as a service, which can be consumed by components. Currently calls to the performance schema instrumentation can be: - not compiled in - static, for calls from the server itself - dynamic, using a function pointer, for calls from server plugins. Calls from server plugins rely on a symbol, (psi_mutex_service, etc), when invoked from plugins. This task to is extend the interface to also expose a service, so that code compiled as a "component" (not as a "plugin") can invoke the performance schema instrumentation.
Functional requirements ======================= This task does not provide any functionality that an end user can see directly in SQL. There is no externally observable change. Non functional requirements =========================== NF-1: Provide a service for mysql_mutex NF-2: Provide a service for mysql_rwlock NF-3: Provide a service for mysql_cond NF-4: Provide a service for psi_cond NF-5: Provide a service for psi_error NF-6: Provide a service for psi_file NF-7: Provide a service for psi_idle NF-8: Provide a service for psi_mdl NF-9: Provide a service for psi_memory NF-10: Provide a service for psi_mutex NF-11: Provide a service for psi_rwlock NF-12: Provide a service for psi_socket NF-13: Provide a service for psi_stage NF-14: Provide a service for psi_statement NF-15: Provide a service for psi_table NF-16: Provide a service for psi_thread NF-17: Provide a service for psi_transactions
Currently, the performance schema exposes low level interfaces for the following instrumentation: - conditions - data locks (in C++, for storage engines) - error - file I/O - idle - metadata locking - memory - rwlock / prlock / sxlock - socket - statements - stages - table I/O and table lock - thread - transactions This task adds services interfaces, callable from components, for the following instrumentation: - conditions - error - file I/O - idle - metadata locking - memory - rwlock / prlock / sxlock - socket - statements - stages - table I/O and table lock - thread - transactions In other words, all existing instrumentation interfaces are also exposed as services, with the exception of data locks. Rationale for not having a data lock "service" : - Data locks can not be exposed as is, because services can not use a C++ api. - Data locks are used only by storage engines, currently INNODB. Storage engines are not implemented as components, so there would be no calling code using this new service. In addition to all these new services, the following are also exposed: - a service for mysql_mutex - a service for mutex_rwlock / mysql_prlock - a service for mysql_cond These services hide completely both the underlying implementation (pthread) and the underlying instrumentation (performance schema) from components. Rationale for including these in scope: - without it, component code could call the **instrumentation** part of a mutex with a service, but still could not call the mutex implementation **itself**, because that still require dependencies on mysys. - so without it, the goal to implement instrumented code in a component can not be met.
Copyright (c) 2000, 2019, Oracle Corporation and/or its affiliates. All rights reserved.