QUERY_HISTORY view
Organization admins can also see a 24-hour summary of activity across every Duckling in the organization under Settings → Duckling overview. See Duckling overview for details.
You can monitor and cancel running queries in the MotherDuck UI under Settings → Running Queries. See Running Queries for details.
The MD_INFORMATION_SCHEMA.QUERY_HISTORY view provides organization admins with a consolidated view of all queries run across their full organization. This view is available on Business plans and only to organization admins.
Schema
When you query the MD_INFORMATION_SCHEMA.QUERY_HISTORY view, the query results contain one row for each query that was run in the organization. Note that the information in this view will have some delays. A more realtime view of ongoing and completed queries that have not been captured in QUERY_HISTORY yet is provided through the MD_INFORMATION_SCHEMA.RECENT_QUERIES view.
The MD_INFORMATION_SCHEMA.QUERY_HISTORY view has the following schema:
| Column Name | Data Type | Value |
|---|---|---|
| QUERY_ID | UUID | A unique ID representing the particular query run. You can retrieve this value on the client with MD_LAST_QUERY_ID(). |
| QUERY_TEXT | STRING | Query SQL text (up to 100k chars) |
| START_TIME | TIMESTAMPTZ | Start time of the query |
| END_TIME | TIMESTAMPTZ | End time of the query |
| EXECUTION_TIME | INTERVAL | Duration where the query is actively executing |
| WAIT_TIME | INTERVAL | Duration where the query is waiting on resources to become available. For example a query needs to wait because other queries are using all available execution threads, or a query might be waiting on data to become available (in case of data upload). |
| TOTAL_ELAPSED_TIME | INTERVAL | Total duration of the query |
| ERROR_MESSAGE | STRING | Error message, if the query returned an error |
| ERROR_TYPE | STRING | Error type, if the query returned an error |
| USER_AGENT | STRING | User agent of the client |
| USER_NAME | STRING | Identifier for the MotherDuck user in their organization |
| QUERY_NR | UBIGINT | ID of the query within the transaction that ran the query. Number that just increments for each query that is run within a given transaction |
| TRANSACTION_NR | UBIGINT | ID of the transaction that contained the query. Number that just increments for each new transaction on a given connection |
| CONNECTION_ID | UUID | Unique ID for the client DuckDB connection where the query was issued |
| DUCKDB_ID | UUID | Unique ID for the client DuckDB instance where the query was issued |
| DUCKDB_VERSION | STRING | Client DuckDB version that issued the query |
| INSTANCE_TYPE | STRING | The size of Duckling that the query was run on (Pulse / Standard / Jumbo / Mega / Giga / ...) |
| QUERY_TYPE | STRING | The nature of the query (DDL / DML / QUERY / ...) |
| BYTES_UPLOADED | UBIGINT | Number of bytes uploaded from client to server (relevant for hybrid queries) |
| BYTES_DOWNLOADED | UBIGINT | Number of bytes downloaded from server to client (relevant for hybrid queries) |
| BYTES_SPILLED_TO_DISK | UBIGINT | Total number of bytes spilled to disk for "larger than in-memory" workloads |
| DUCKLING_ID | STRING | Identifies the duckling that ran the query. It is composed of the user name and a qualifier (rw for read-write ducklings, or rs.0, rs.1, ... for the respective read scaling duckling) |
| SESSION_NAME | STRING | The session_name that was supplied when connecting to MotherDuck |
The fields START_TIME, END_TIME, TOTAL_ELAPSED_TIME, ERROR_MESSAGE, and ERROR_TYPE are captured on the server (that is, when query starts and ends on server). In the future they will be based on client information too (taking better into account the full hybrid context).
Example usage
from MD_INFORMATION_SCHEMA.QUERY_HISTORY limit 10;