MV_QUERY_ACTIVITIES_EXTENDED_CUMULATIVE

node_id

An ID equal to id in the row of mv_nodes describing the node on which the activity’s instances have run.

activity_name

An ID shared by all instances of the activity. This ID is often human-readable, but does not include the query text for query tasks. This will be the activity_name of all query tasks associated with the query. See mv_queries.

aggregator_activity_name

The aggregator_activity_name of the activity.

query_text

The de-parameterized text of the query.

aggregator_query_text

The aggregator query text.

database_name

The name of the database associated with the query, or NULL if none could be assigned.

partition_id

The unique ID of the database partition associated with the query, or NULL if none could be assigned.

cpu_time_ms

Milliseconds spent running on a CPU. If elapsed_time_ms of a leaf query task is equal to cpu_time_ms, you should PROFILE the query.

cpu_wait_time_ms

Milliseconds spent waiting for a CPU to become available. A non-zero value indicates that there were more concurrent tasks in the workload than there were CPUs on which to run them. If this value is a significant amount of elapsed time, the workload is likely issuing its queries faster than the hardware can handle. Investigate the tasks with the highest cpu_time_ms and optimize the relevant queries, reduce your workload, or provision more CPUs for your cluster.

elapsed_time_ms

Wall clock milliseconds elapsed during execution.

lock_row_time_ms

Milliseconds spent waiting on table row locks.

lock_time_ms

Milliseconds spent waiting on locks and condition variables, excluding row locks. This isn’t solely wait time due to contention on data structures because it also includes some time spent waiting for events in general.

disk_time_ms

Milliseconds spent waiting for physical disk I/O to complete. If this value is high, it may indicate excessive time to commit transactions to storage. You may need hardware which supports a faster write rate, or you may need to investigate whether other processes are issuing too much I/O and introducing unwanted variability. Check which other queries are using disk_physical_read_b or disk_physical_write_b.

network_time_ms

Milliseconds spent waiting for sockets to be ready to send or receive data. This may indicate that leaves are slow to respond to a query, or that a distributed join involves a large data transfer. If this counter has a noticeable delay, check what other queries are consuming network_logical_recv_b and network_logical_send_b.

log_buffer_time_ms

Milliseconds spent waiting for space in the transaction log buffer. If this value is nonzero, it is usually indicative of disk issues. See disk_time_ms.

log_flush_time_ms

Milliseconds spent waiting for transaction log records to be flushed to disk. If this value is nonzero, it is usually indicative of disk issues. See disk_time_ms.

network_logical_recv_b

Bytes received from a socket.

network_logical_send_b

Bytes written to a socket.

disk_logical_read_b

Bytes read from the filesystem.

disk_logical_write_b

Bytes written to the filesystem.

disk_physical_read_b

Bytes actually read from physical disk. This may be higher or lower than the logical number due to hardware and operating system artifacts and optimizations.

disk_physical_write_b

Bytes actually written to physical disk. This may be higher or lower than the logical number due to hardware and operating system artifacts and optimizations.

memory_bs

Byte-seconds of memory used.

memory_major_faults

Number of page faults which required disk I/O to resolve.

pipeline_extractor_wait_ms

The amount of time, in seconds, that the pipeline spent waiting on the extractor to complete its operation.

pipeline_trasnform_wait_ms

The amount of time, in seconds, that the pipeline spent waiting on the transform to complete its operation.

run_count

The number of instances which were running at the end of the interval (since the plan was generated).

success_count

The number of instances which completed successfully during the interval (since the plan was generated).

failure_count

The number of instances which completed unsuccessfully during the interval (since the plan was generated).

plan_warnings

The number of warnings generated during query execution.

plan_info

High-level information about the plan, including warnings/errors, etc., intended for debugging. NULL if no information was collected.

BLOB_CACHE_MISS_B

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.

BLOB_CACHE_WAIT_TIME_MS

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.