sql: set up foundations for per-application statistics#14092
sql: set up foundations for per-application statistics#14092knz merged 1 commit intocockroachdb:masterfrom
Conversation
81bd32c to
827fe32
Compare
|
Reviewed 3 of 3 files at r1, 5 of 5 files at r2. pkg/sql/app_stats.go, line 50 at r2 (raw file):
I'm not fond of the name pkg/sql/crdb_internal.go, line 235 at r3 (raw file):
Comments from Reviewable |
|
Review status: 7 of 10 files reviewed at latest revision, 2 unresolved discussions, all commit checks successful. pkg/sql/app_stats.go, line 50 at r2 (raw file): Previously, petermattis (Peter Mattis) wrote…
Done. pkg/sql/crdb_internal.go, line 235 at r3 (raw file): Previously, petermattis (Peter Mattis) wrote…
Done (we don't use lowercase for virtual tables, for some reason). Comments from Reviewable |
This patch instruments the SQL executor with a data structure aimed at collecting per-application statistics and exposes it via a new virtual table `crdb_internal.app_stats`. An "application" is identified by setting the session variable "application_name". Each application has a separate instance of a new struct `appStats`. The pointer to this struct is cached in the session object and updated only when the application name is modified. However since there can be multiple sessions updating a single `appStats` instance concurrently, its fields must be properly synchronized. The separation of statistics per application is motivated both by a user-expressed interest in separating statistics per application, and by a performance concern -- reducing contention on the mutex on the map holding all the appStats instances.
This patch instruments the SQL executor with a data structure aimed at
collecting per-application statistics, then exposes this data
structure via a new virtual table
crdb_internal.app_stats.An "application" is identified by setting the session variable
"application_name".
Each application has a separate instance of a new struct
appStats.The pointer to this struct is cached in the session object and updated
only when the application name is modified.
However since there can be multiple sessions updating a single
appStatsinstance concurrently, its fields must be properlysynchronized.
The separation of statistics per application is motivated both by a
user-expressed interest in separating statistics per application, and
by a performance concern -- reducing contention on the mutex on the
map holding all the appStats instances.
Needed for #13968.
(This PR is based off #14089 and will be rebased once #14089 merges.)
This change is