> ## Documentation Index > Fetch the complete documentation index at: https://cockroachlabs.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Insights Page export const InternalLink = ({version, path = "", children, ...props}) => { let detectedVersion = version || "stable"; if (typeof window !== 'undefined' && !version) { const match = window.location.pathname.match(/\/docs\/([^/]+)/); if (match) { detectedVersion = match[1]; } } const normalizedPath = path.startsWith("/") ? path.slice(1) : path; return {children} ; }; export const version = "stable"; On a secure cluster, you must be an `admin` user or a SQL user with the `VIEWACTIVITY` or `VIEWACTIVITYREDACTED` system privilege (or the legacy `VIEWACTIVITY` role option) to access this area of the DB Console. Refer to DB Console security. The **Insights** page exposes problems that CockroachDB has detected in your workloads and schemas. The page also offers recommendations to improve the performance of your workloads. These are called *insights* in the DB Console. The **Insights** page helps you: * Identify SQL statements with high retry counts, slow execution, or suboptimal plans. * Identify indexes that should be created, altered, replaced, or dropped to improve performance. ## Workload Insights tab The **Workload Insights** tab displays insights related to transaction and statement executions. ### Transaction Executions view To display this view, click **Insights** in the left-hand navigation of the DB Console and select **Workload Insights > Transaction Executions**. The **Transaction Executions** view provides an overview of all transaction executions that have been flagged with insights. The rows in this page are populated from the `crdb_internal.transaction_contention_events` and `crdb_internal.cluster_txn_execution_insights` tables. * The results displayed in the **Transaction Executions** view will be available as long as a corresponding row in the `crdb_internal.transaction_contention_events` or `crdb_internal.cluster_txn_execution_insights` tables exists. The rows in `crdb_internal.transaction_contention_events` on each node must use less space than `sql.contention.event_store.capacity`, and the rows in `crdb_internal.transaction_contention_events` cannot exceed `sql.insights.execution_insights_capacity`. * The default tracing behavior captures a small percent of transactions so not all contention events will be recorded. When investigating transaction contention, you can set the `sql.trace.txn.enable_threshold` cluster setting to always capture contention events. The transaction insights table has the following columns: | Column | Description | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Latest Transaction Execution ID | The execution ID of the latest execution with the transaction fingerprint. To view [details of the execution](#transaction-execution-details), click the execution ID. | | Transaction Fingerprint ID | The transaction fingerprint ID of the latest transaction execution. | | Transaction Execution | The transaction fingerprint of the latest transaction execution. | | Status | The status of the transaction: `Failed` or `Completed`. | | Insights | The [insight type](#workload-insight-types) for the transaction execution. | | Start Time (UTC) | The timestamp when the transaction execution started. | | Contention Time | The amount of time the transaction execution spent waiting in contention. | | CPU Time | The amount of CPU time spent executing the transaction. The CPU time represents the time spent and work done within SQL execution operators. The CPU time includes time spent in the SQL layer. It does not include time spent in the storage layer. | | Application Name | The name specified by the `application\_name` session setting. | ### Transaction Execution details The transaction execution details view provides more information on a transaction execution insight. #### Default details This information is displayed for all insight types. | Field/Column | Description | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Start Time | The timestamp when the transaction execution started. | | End Time | The timestamp when the transaction execution ended. | | Elapsed Time | The time that elapsed during transaction execution. | | CPU Time | The amount of CPU time spent executing the transaction. The CPU time represents the time spent and work done within SQL execution operators. The CPU time includes time spent in the SQL layer. It does not include time spent in the storage layer. | | Rows Read | The total number of rows read by the transaction execution. | | Rows Written | The total number of rows written by the transaction execution. | | Priority | The priority of the transaction execution. | | Number of Retries | The total number of retries of the transaction. | | Session ID | The ID of the session the transaction was executed from. | | Application | The name specified by the `application\_name` session setting. | | Transaction Fingerprint ID | The fingerprint ID of the transaction execution. To view details of the transaction, click the fingerprint ID. | | Insights | The [insight type](#workload-insight-types). | | Details | Provides details on the insight. For example, if the insight type is High Contention, **Time Spent Waiting** and **Description** are displayed. If the insight type is Failed Execution, **Error Code** and **Error Message** are displayed. | #### Conditional details Additional information is displayed for the following insight types: 1. [**High Contention**](#high-contention): All transaction executions flagged with this insight type will display a **Transaction with ID \{transaction ID} waited on** section which provides details of the blocking transaction execution. 2. [**Failed Execution**](#failed-execution): Certain transaction executions flagged with this insight type will display a **Failed Execution** section with **Conflicting Transaction** and **Conflicting Location** information. The following 3 conditions are required: * The `sql.contention.record_serialization_conflicts.enabled` cluster setting is set to `true` (default). * **Error Code** is `40001`, a `serialization_failure`. * **Error Message** includes `RETRY_SERIALIZABLE` `- failed preemptive refresh due to conflicting locks`. | Field/Column | Insight Type(s) | Description | | -------------------------------- | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Transaction Execution \[ID] | High Contention, Failed Execution | The execution ID of the blocking or conflicting transaction execution. | | Transaction Fingerprint \[ID] | High Contention, Failed Execution | The transaction fingerprint ID of the blocking or conflicting transaction execution. For a Failed Execution, view details of the transaction fingerprint by clicking the transaction fingerprint ID. | | Statement Waiting Execution ID | High Contention | The execution ID of the waiting statement. | | Statement Waiting Fingerprint ID | High Contention | The statement fingerprint ID of the waiting statement. | | Transaction Execution | High Contention | The queries attempted in the transaction. | | Contention Start Time (UTC) | High Contention | The timestamp at which contention was detected for the transaction. | | Contention Time | High Contention | The time that transactions with this execution ID were in contention with other transactions within the specified time interval. | | Schema Name | High Contention | The name of the contended schema. | | Database \[Name] | High Contention, Failed Execution | The name of the contended or conflicting database. | | Table \[Name] | High Contention, Failed Execution | The name of the contended or conflicting table. | | Index \[Name] | High Contention, Failed Execution | The name of the contended or conflicting index. | ### Statement Executions view The **Statement Executions** view provides an overview of all statement executions that have been flagged with insights. To display this view, click **Insights** in the left-hand navigation of the DB Console and select **Workload Insights > Statement Executions**. The rows in this page are populated from the `crdb_internal.cluster_execution_insights` table. * The results displayed on the **Statement Executions** view will be available as long as the number of rows in each node is less than the `sql.insights.execution_insights_capacity` cluster setting. * The default tracing behavior captures a small percent of transactions, so not all contention events will be recorded. When investigating transaction contention, you can set the `sql.trace.txn.enable_threshold` cluster setting to always capture contention events. Click **Columns** to select the columns to display in the table. The statement insights table has the following columns available: | Column | Description | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Latest Statement Execution ID | The execution ID of the latest execution with the statement fingerprint. To view [details of the execution](#statement-execution-details), click the execution ID. | | Statement Fingerprint ID | The statement fingerprint ID of the latest statement execution. | | Statement Execution | The statement fingerprint of the latest statement execution. | | Status | The status of the transaction: `Failed` or `Completed`. | | Insights | The [insight type](#workload-insight-types) for the statement execution. | | Start Time (UTC) | The timestamp when the statement execution started. | | Elapsed Time | The time that elapsed to complete the statement execution. | | User Name | The name of the user that invoked the statement execution. | | Application Name | The name specified by the `application\_name` session setting. | | Query Tags | The [query tags](#query-tags) extracted from comments in the statement query. When set appropriately, these tags can provide application context and help correlate query performance with client-side application state. | | Rows Processed | The total number of rows read and written. | | Retries | The number of times the statement execution was retried. | | Contention Time | The amount of time the statement execution spent waiting in contention. | | SQL CPU Time | The amount of CPU time spent executing the statement. The CPU time represents the time spent and work done within SQL execution operators. The CPU time includes time spent in the SQL layer. It does not include time spent in the storage layer. | | Full Scan | Whether the execution performed a full scan of the table. | | Transaction Fingerprint ID | The ID of the transaction fingerprint for the statement execution. | | Latest Transaction Execution ID | The ID of the transaction execution for the statement execution. | #### Query tags The **Query Tags** column displays the comments embedded in SQL statements, as defined by the [SQL commenter specification](https://google.github.io/sqlcommenter/spec). These comments, referred to as *query tags*, must be instrumented by the user and can include application context such as the application name, user ID, or feature flags. This information helps correlate slow query performance with specific application states. The **Query Tags** column is available in the **Statement Executions** view's **Statement Insights** table, but is hidden by default. To display it, use the **Columns** selector. Query tags are also included in the following locations: * The [**Statement Execution** details](#statement-execution-details) page * All log entries generated during the execution of a SQL statement (prefixed with `querytag-` ) * Traces (prefixed with `querytag-` ) * The `crdb_internal.cluster_execution_insights` and `crdb_internal.node_execution_insights` virtual tables, in a new `query_tags` JSONB column This feature is disabled by default. To enable it, set the `sql.sqlcommenter.enabled` cluster setting to `true`. To test this functionality, you can generate a SQL query with a [Slow Execution](#slow-execution), then view it on the **Insights** page: 1. Enable SQL commenter query tagging: ```sql theme={"theme":{"light":"catppuccin-mocha","dark":"catppuccin-mocha"}} SET CLUSTER SETTING sql.sqlcommenter.enabled=true; ``` 2. Check the value of cluster setting `sql.insights.latency_threshold`: ```sql theme={"theme":{"light":"catppuccin-mocha","dark":"catppuccin-mocha"}} SHOW CLUSTER SETTING sql.insights.latency_threshold; ``` 3. Execute the following statement, using a `pg_sleep` value greater than the `latency_threshold`: ```sql theme={"theme":{"light":"catppuccin-mocha","dark":"catppuccin-mocha"}} SELECT pg_sleep(2) /*db_driver='test_driver',db_framework='test_framework',db_backend='cockroachdb'*/; ``` 4. On the Insights page, in the **Columns** selector, check **Query Tags** and click **Apply**. 5. For the row where **Statement Execution** is `SELECT pg_sleep()`, scroll to the right to see the key-value pairs from the SQL comment displayed in the **Query Tags** column.

6. On the same row, click on the **Latest Statement Execution ID** (the first column on the left) to open the [**Statement Execution** details](#statement-execution-details) page. These key-value pairs also appear on the **Overview** tab under **Query Tags**. ### Statement Execution details The statement execution details view provides more information on a statement execution insight. #### Default details This information is displayed for all insight types. | Field/Column | Description | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Start Time | The timestamp when the statement execution started. | | End Time | The timestamp when the statement execution ended. | | Elapsed Time | The time that elapsed during statement execution. | | SQL CPU Time | The amount of CPU time spent executing the statement. The CPU time represents the time spent and work done within SQL execution operators. The CPU time includes time spent in the SQL layer. It does not include time spent in the storage layer. | | Rows Read | The total number of rows read by the statement execution. | | Rows Written | The total number of rows written by the statement execution. | | Transaction Priority | The priority of the transaction for the statement execution. | | Full Scan | Whether the execution performed a full scan of the table. | | Transaction Retries | The total number of retries of the transaction for the statement execution. | | Session ID | The ID of the session the statement was executed from. | | Transaction Fingerprint ID | The ID of the transaction fingerprint for the statement execution. | | Transaction Execution ID | The ID of the transaction execution for the statement execution. | | Statement Fingerprint ID | The fingerprint ID of the statement fingerprint for the statement execution. | | Query Tags | The [query tags](#query-tags) extracted from comments in the statement query. When set appropriately, these tags can provide application context and help correlate query performance with client-side application state. | | Insights | The [insight type](#workload-insight-types). | | Details | Provides details on the insight. For example, if the insight type is High Contention, **Time Spent Waiting** and **Description** are displayed. If the insight type is Failed Execution, **Error Code** and **Error Message** are displayed. | #### Conditional details This information is displayed for only the [**High Contention**](#high-contention) insight type. All statement executions flagged with this insight type will display a **Statement with ID \{statement ID} waited on** section which provides details of the blocking transaction execution. | Column | Description | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Transaction Execution ID | The execution ID of the blocking transaction execution. | | Transaction Fingerprint ID | The transaction fingerprint ID of the blocking transaction execution. | | Contention Time | The time that transactions with this execution ID were in contention with other transactions within the specified time interval. | | Database Name | The name of the contended database. | | Schema Name | The name of the contended schema. | | Table Name | The name of the contended table. | | Index Name | The name of the contended index. | ## Workload Insight types The Workload Insights tab surfaces the following type of insights: * [Failed Execution](#failed-execution) * [High Contention](#high-contention) * [High Retry Count](#high-retry-count) * [Slow Execution](#slow-execution) * [Suboptimal Plan](#suboptimal-plan) ### Failed Execution The transaction or statement execution failed. The following screenshot shows a failed transaction execution:

The following screenshot shows the default details of the preceding failed transaction execution. Failed transaction execution details

The **Insights** column shows the name of the insight, in this case **Failed Execution**. The **Details** column provides the **Error Code** and **Error Message**. CockroachDB uses [PostgreSQL Error Codes](https://www.postgresql.org/docs/current/errcodes-appendix). In this example, Error Code `40001` is a `serialization_failure`. #### Serialization conflict due to transaction contention The following screenshot shows the conditional details of the preceding failed transaction execution. In this case, there was a *serialization conflict*, also known as an *isolation conflict*, due to transaction contention. (For transaction contention that causes *lock contention*, see [High Contention](#high-contention)).

Failed transaction execution details conditional

To capture more information in the event of a failed transaction execution due to a serialization conflict, set the `sql.contention.record_serialization_conflicts.enabled` cluster setting to `true` (default). With this setting enabled, when the **Error Code** is `40001` and the **Error Message** specifically has `RETRY_SERIALIZABLE - failed preemptive refresh``due to conflicting locks`, a conditional **Failed Execution** section is displayed with **Conflicting Transaction** and **Conflicting Location** information. To troubleshoot, refer to the performance tuning recipe for transaction retry errors. ### High Contention The transaction or statement execution experienced high contention time according to the threshold set in the `sql.insights.latency_threshold` cluster setting. This type of contention is also known as *lock contention*. (For transaction contention that causes *serialization conflict*, see [serialization conflict due to transaction contention](#serialization-conflict-due-to-transaction-contention).) To troubleshoot, refer to the performance tuning recipe for identifying and unblocking a waiting transaction. The following screenshot shows the execution of a transaction flagged with **High Contention**:

The following screenshot shows the execution details of the preceding transaction execution: Transaction execution details

### High Retry Count The statement execution experienced a high number of retries according to the threshold set in the `sql.insights.high_retry_count.threshold` cluster setting. ### Slow Execution The statement (or a statement in the transaction) experienced slow execution. Depending on the settings in [Configuration](#configuration), either of the following conditions trigger this insight: * Execution time is greater than the value of the `sql.insights.latency_threshold` cluster setting. * Anomaly detection is enabled ( `sql.insights.anomaly_detection.enabled` ), execution time is greater than the value of `sql.insights.anomaly_detection.latency_threshold`, and execution latency is greater than the p99 latency and more than double the median latency. For details, see [Detect slow executions](#detect-slow-executions). ### Suboptimal Plan The plan could be improved for some statement(s) in the transaction execution. Possible causes include outdated statistics and missing indexes. The statement execution has resulted in one or more [index recommendations](#schema-insights-tab) that would improve the plan. The following screenshot shows the statement execution of the query described in Use the right index:

The following screenshot shows the execution details of the preceding statement execution: Statement execution details

The **Insights** column shows the name of the insight, in this case **Suboptimal Plan**. The **Details** column provides details on the insight, such as a **Description** with the cause of the suboptimal plan and a **Recommendation** with a `CREATE INDEX` statement. The final column contains a **Create Index** button. Click the **Create Index** button to execute the recommended statement to mitigate the cause of the insight. ## Schema Insights tab To display this view, click **Insights** in the left-hand navigation of the DB Console and select **Schema Insights**. This view lists the indexes that have not been used and should be dropped, and/or the ones that should be created, altered, or replaced (based on statement execution). * The drop recommendations are the same as those on the **Databases** page. * The create, alter, and replace recommendations are the same as those on the Explain Plans tab on the Statements page. Whereas the **Explain Plans** tab shows all recommendations, the **Schema Insights** view shows only the latest recommendations for that statement fingerprint. If you execute a statement again after creating or updating an index, the recommendation disappears. The following screenshot shows the insight that displays after you run the query described in Use the right index six or more times: Schema insight