This view contains information about all query statements that SingleStore has compiled and executed, as well as cumulative query execution statistics associated with each plan.

It shows all plans that are currently in SingleStore’s in-memory plancache - plans are removed from this view, and statistics and counters are reset to zero, when the plan expires (after being unused for the setting of the engine variable plan_expiration_minutes), when the node restarts, or when the plan must be recompiled or reloaded (e.g. when the table is altered).

See also SHOW PLANCACHE, which displays a subset of this information.

Column Name



Context database selected with USE <database_name> when query was compiled.


Query text with all numeric and string parameters replaced by tags (depending on parameter and/or query type). @ is used for integers and ^ for string parameters. ? is always used for INSERT queries.


The unique ID of the query plan. Please note, when executing the same query from different clients, two plans are generated with a different PLAN_ID in the plancache.


The type of query plan: interpreted or compiled.


The number of successful executions of a given query.


Number of unsuccessful executions of a given query (i.e. cases where query was aborted or encountered runtime errors).


The cumulative number of rows returned by a SELECT query or the cumulative number of rows inserted, updated, or deleted for an INSERT, UPDATE, or DELETE query.


The cumulative time, in milliseconds, spent executing a given query (from the time the query arrived at the server to the time the result was sent to the client). This includes time spent waiting while queued. To find the working time of a query use: execution_time - queued_time.


The average execution time (in milliseconds) of a given query plan.


NULL for SELECT queries, otherwise the cumulative time (in milliseconds) spent waiting to reserve space in the transaction buffer for this query. A larger transaction buffer and faster disk can help reduce it.


NULL for SELECT queries, otherwise the cumulative time (in milliseconds) spent waiting until changes made by this query are flushed to disk. A faster disk can help reduce it.


NULL for SELECT queries, otherwise the cumulative time (in milliseconds) spent waiting to acquire exclusive row locks.


Cumulative number of rows at the cluster level streamed from leaves and processed by a given SELECT query.


Cumulative time, in milliseconds, at the cluster level spent waiting for results from leaves. This includes the time spent executing queries on the 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. Any temporary memory allocation needed to execute a query (including those for hash tables, sorts, result tables, etc.) is tracked here.


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.


The amount of CPU time, in milliseconds, spent executing the query.


This is the maximum memory use (in bytes) of each run, averaged across all runs of the same query plan.


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. This is a sum of waiting time from all query execution threads, not to be compared with end-to-end running time.


The ID of the related activity.


The values of all engine variables that affect a given query plan.


A query sometimes cannot find its input data in blob cache, referred to as a cache miss. The blob cache will download the missing data from the unlimited storage. This new field tells us the number of bytes downloaded from the unlimited storage.

Last modified: April 22, 2024

Was this article helpful?