Important
Helios features are now enabled during weekly update windows and are no longer directly tied to SingleStore engine releases. Refer to the release notes to view the latest features available in your Helios cluster.
MV_ PLANCACHE
MV_ shows plancache information for all nodes in the cluster.
MV_ shows all plans that are currently in SingleStore’s in-memory plancache for all nodes in the cluster; it does not provide a permanent history.
-
The plan remains unused for the duration specified by the
plan_engine variableexpiration_ minutes -
The node restarts
-
The plan is recompiled or reloaded, for example, after a table is altered.
MV_ does not show plans held on disk.
|
Column Name |
Description |
|---|---|
|
|
The ID of the node. |
|
|
Context database selected with |
|
|
Query text with all numeric and string parameters replaced by tags (depending on parameter and/or query type). |
|
|
The unique |
|
|
Indicates whether the plan was compiled with profiling enabled.
|
|
|
Profile codegen mode used when compiling the plan.
|
|
|
Specifies Feedback Reoptimization (FR) state for this plan.
|
|
|
Specifies the Feedback Reoptimization (FR) iteration at which this plan was compiled.
|
|
|
The type of query plan: interpreted or compiled. Potential values: |
|
|
The number of successful executions of a given query. |
|
|
Number of unsuccessful executions of a given query, including cases where the query was aborted or encountered a runtime error. Use this information to identify the statements contributing to the failed-query counter on a node, i. |
|
|
The cumulative number of rows returned by a |
|
|
The cumulative time, in milliseconds, spent executing a given query. |
|
|
The average execution time (in milliseconds) of a given query plan. |
|
|
|
|
|
|
|
|
|
|
|
Cumulative number of rows at the cluster level streamed from leaves and processed by a given |
|
|
Cumulative time, in milliseconds, at the cluster level spent waiting for results from leaves. |
|
|
The amount of time, in milliseconds, a given query spent queued by Workload Management. |
|
|
The amount of time, in milliseconds, a given query spent queued by Resource Governance. |
|
|
The path to the plan files on disk. |
|
|
The total amount of time, in milliseconds, a given query spends queued. |
|
|
The timestamp at which a given query was first created or loaded from disk. |
|
|
The timestamp at which a given query was last executed. |
|
|
The average amount of memory used (in bytes) to execute this query, over time. |
|
|
Any warnings associated with a given query plan. |
|
|
Additional information about the query plan, in JSON format. |
|
|
Information about the query plan used by the optimizer, in JSON format. This value is only populated on aggregator nodes. |
|
|
The amount of CPU time, in milliseconds, spent executing the query. |
|
|
This is the maximum memory use (in bytes) of all of the operators used in each run, averaged across all runs of the same query plan, over time. |
|
|
The average amount of data (in bytes) spilt to disk during query execution. |
|
|
The average number (in bytes) that could not be found in the blob cache and had to be downloaded from the unlimited storage. |
|
|
The time (milliseconds) that were spent on waiting for blob cache data. |
|
|
The |
|
|
The values of all engine variables that affect a given query plan. |
Use REOPTIMIZE_, REOPTIMIZE_, and OPTIMIZER_ together to understand how Feedback Reoptimization has interacted with a given plan.MV_ exposes both the original plan and FR-derived plans (if any) as separate rows.
Last modified: