This setting enables the job that transfers top-k fingerprints from the last 2 hours from system.{statement,transaction}_statistics to system.{statement,transaction}_activity.
These activity tables were introduced to speed up sql activity requests from the db-console ui. It has been determined that for workloads with high fingerprint cardinality, these tables are too expensive to maintain (the job must apply a top-k sort for recent aggregation intervals in the source tables, which can lead to contention and is generally slow when we have a lot of data). Moreover, they may not be usable in those workloads due to the fact that the time required for both the flush and the job to complete.
For low-average fingerprint cardinality workloads, there is a lesser need for the activity tables so we should just turn this off by default.
When turning off this cluster setting, we also need to disable reading from the cache via the CS sql.stats.activity.ui.enabled.
This setting enables the job that transfers top-k fingerprints from the last 2 hours from
system.{statement,transaction}_statistics
tosystem.{statement,transaction}_activity
.These activity tables were introduced to speed up sql activity requests from the db-console ui. It has been determined that for workloads with high fingerprint cardinality, these tables are too expensive to maintain (the job must apply a top-k sort for recent aggregation intervals in the source tables, which can lead to contention and is generally slow when we have a lot of data). Moreover, they may not be usable in those workloads due to the fact that the time required for both the flush and the job to complete.
For low-average fingerprint cardinality workloads, there is a lesser need for the activity tables so we should just turn this off by default. When turning off this cluster setting, we also need to disable reading from the cache via the CS
sql.stats.activity.ui.enabled
.Jira issue: CRDB-38194
Epic CRDB-39643